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engine firing. A combined component-based and process theory 
approach is adopted as the basis for system modeling. Such an 
approach provides a framework for explaining both normal and 
deviant system behavior in terms of individual component 
functionality. The diagnosis function is applied to digitized 
sensor time-histories generated during engine firings. The 
generic system is applicable to any liquid rocket engine but has 
been adapted specifically in this work to the Space Shuttle Main 
Engine (SSME) . The system is applied to idealized data 
resulting from turbomachinery malfunction in the SSME. 
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1 . INTRODUCTION 


The task of post-test analysis and diagnosis of data 

.-22 5 %^* 

^T-to-i^Te 

a ° f 

caused^hen^experts _ retir^or^othervise ^eav^the^eam'^their 
replacement is difficult. 

To help alleviate the manpower problem associated with data 
review? an imated system is needed to provide assistant to 
i-he experts Such a system would be implemented on a digital 

co^?? r woiid be capabl^ of analysing J^tx^t-tdjt.^ 
identifying normal and anomalous firing data f .. 

capable of formulating hypotheses about the cause of the 
anomalous results. Furthermore, the system should be capable of 
justifying and explaining the stated hypotheses and recommending 
further actions to better identify the causes of the anomalies. 

Current research in the development of diagnostic systems 
for rocket engine firing focuses on such approaches as expert 
mtSS [1 2]? Neural networks [3-6], and signal processing 
systems t 1 ' 2 ( [; a ^ ional expert systems developed from the 

associational knowledge of human experts tend to have a very 
narrow scope both in terms of the extent °fthedomainand range 

of problem solving activities they can fi? system 

svstems do not provide sufficient flexibility for system 
modi f icat ion - modification of the object of interest often 
calls for the development of a new expert system. 

Model-based approaches [10-12] which integrate fundamental 
principles, causal and common sense knowledge are capable of 
overcoming the limitations of traditional expert systems 

several ?ecent applications of ?V al ^ at ^ e th ? r t asral hand ? 
diagnostic approaches appear applicable to the task at hand 

the analysis and diagnosis of rocket engine data [13,14]. 

in what follows, a description of the model-based approach 
is discussed in a generic sense prior to application of the 
concept to the SSME system. 
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2.0 REVIEW OF DIAGNOSTIC APPROACHES 


Before focusing on the particular application (SSME) and 
diagnostic system (EDIS) of primary interest here, a general 
review of the approaches other researchers have pursued seems 
appropriate. Relevant "Artificial Intelligence" (AI) literature 
includes previous work on knowledge-based analysis and diagnosis 
of the SSME and other space-related engineering systems. In 
what follows, approaches taken by researchers considering 
diagnostic systems similar to the SSME are summarized. 

2 . 1 Generic Diagnostic Paradigm 

Work on diagnostic systems by Davis [13] and Genesereth 

[15] and promising results in reasoning from first principle 

[16] have made model-based reasoning an attractive option for 
diagnostic systems. In particular, model-based reasoning allows 
diagnosis to be performed without explicit fault assumptions. A 
fault is simply characterized by a component not behaving as 
desired without reference to a specific aberration, see Davis 

[17] , Constraints are used to specify correct component 
behavior. A constraint is a qualitative or quantitative 
relationship between the parameters which describe the behavior 
of a component. A component fault can thus be defined as the 
violation of one or more constraints associated with the 
component. Model-based diagnosis using constraint propagation 
potentially covers all possible faults of a device, not only 
those explicitly enumerated by an expert. Diagnostic 
completeness is, however, limited by the accuracy and 
completeness of the model [17]. For example, parasitic causal 
pathways may exist between components, such as heat transport or 
crosstalk, which cannot be detected if the relevant kind of 
component interaction has not been modeled. 

Diagnostic paradigms have been formulated based on the 
availability of a model which contains device structure, i.e., a 
decomposition of the device into interconnected components, and 
behavior constraints for all components of the device. For 
example, Davis [17] introduced "constraint suspension" and 
Genesereth 's DART [15] program uses the "resolution residue" 
procedure. Most diagnostic procedures follow the Generate - 
Test - Discriminate paradigm. In the first step, fault 
hypotheses are generated. A hypothesis may explicitly enumerate 
a specific set of components which are assumed to be faulty, or 
a hypothesis may be implicitly defined by a set of components at 
least one of which must be faulty. The set of hypotheses must 
be complete but it will, in general, contain too many 
candidates, although most designs try to keep the set as small 
as possible. Hypothesis testing eliminates those candidate 
hypotheses which cannot account for all observed symptoms. 
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Theoretically, it is possible to combine hypothesis generation 
and testing, i.e. to generate viable hypotheses only, but in 
practice it often proves simpler to separate these two steps. 
If several hypotheses survive testing, then more data need to be 
observed to discriminate between them. Electronic 
troubleshooting systems must determine the test which promises 
to reveal the most new information. The FIS system [18], the 
IN-ATE approach [19], and the general diagnostic engine (GDE) 
method [20] use probabilistic methods to propose the next "best" 
test. Approaches based on the minimum entropy principle, such as 
GDE, appear to be best. Note, however, that for SSME post-test 
analysis no further tests are possible. 

DeKleer and Williams [20] have presented GDE, a method for 
diagnosing single and multiple faults in systems which can be 
modeled by interconnected modules, each characterized by 
constraints between input and output parameters. Essentially the 
same method has also been proposed by Reiter [21] except that 
his derivation is based on formal logic. GDE predicts values 
for device parameters given some known values, e.g. , measured or 
input values, by propagating the known values through the 
component interconnections and constraint expressions. Note that 
constraints must be non-directional, i.e. the system must be 
able to reason from inputs to outputs as well as from outputs to 
inputs. Davis [13], for example, supplies "simulation" and 
"inference" rules for forward and backward propagation, 
respectively . 

GDE detects a "symptom" when at least two different values 
are predicted (or determined) for the same parameter based on 
different input or measured values. Value prediction depends on 
the assumption that each component which was traversed during 
constraint propagation enforces its constraints correctly. 
Existence of a symptom indicates that at least one constraint 
must be violated and thus one component involved in the symptom 
must be faulty. A component is involved in a symptom if it lies 
on a propagation path which leads to the symptom, i.e. its 
behavior influences the predicted value. A symptom gives rise 
to a set of fault hypotheses. GDE represents hypotheses 
implicitly. Sets of components which contain at least one 
fault, named "conflicts" or "conflict sets", are generated by 
combining all components which were involved in creating the 
symptom. Hypotheses are derived from these conflict sets by 
forming sets of components such that at least one member of each 
conflict set is represented in the hypothesis set. If a 
hypothesis exists which contains only one component then a 
single fault in this component can account for all symptoms. 
Otherwise multiple faults must be present. 

The diagnostic paradigm exemplified by GDE is very powerful 
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but some caution is appropriate before recommending it for every 
diagnostic application. DeKleer and Williams [20] point out 
that complete prediction of component and system behavior is 
currently beyond the state-of-the-art. The SSME [22] is a good 
example of a complex dynamic system whose behavior is very 
difficult to model and to predict. A large numeric 
power-balance model (PBM) [23] is used for post-test data 
reduction and pre-test performance prediction. The PBM searches 
iteratively for a set of consistent engine parameter values. It 
is valid only for normal operation and some small deviations. 
Clearly, such a model cannot be used for constraint propagation, 
because it cannot propagate anomalous parameter values and 
because it cannot perform local propagation at each module. 

2.2 Reduced Prediction Models 

Given that the SSME components cannot be modeled by exact 
constraints, other, less accurate methods of modeling have to be 
explored. Qualitative modeling [16] eliminates the need for 
exact numeric constraint equations. Only qualitative parameter 
values, such as normal, low, high, and their trends, such as 
stable, increasing, decreasing, are considered. Several systems 
have been developed which can perform system simulation using 
qualitative models only, see [16]. In [24], for example, DeKleer 
and Brown define qualitative models for components as sets of 
qualitative state - confluence pairs. Qualitative states loosely 
correspond to operating regions of devices governed by different 
laws. Confluences are equations constraining qualitative values 
of parameters, based on a special qualitative calculus. 
Confluences and qualitative states are usually derived from 
conventional mathematical models. 

Forbus [25] presents another approach to qualitative 
modeling which is process-centered instead of 
component-centered. A process relates the parameters of 
several interacting objects (components). For example, a heat 
flow process is instantiated when a heat source, a heat sink, 
and a heat path are present and properly aligned. 

Qualitative models have the disadvantage that counteracting 
influences lead to multiple possible conclusions about the 
behavior of a parameter value. For example, if two input 
parameters are added to produce the output and the signs ("high" 
or "low") of the inputs do not agree, the sign of the output 
cannot be predicted uniquely. The same holds true for opposite 
trends at the inputs. Predictive ability is limited because the 
relative strengths of conflicting influences are not 
represented. 

Subsequently, researchers have modified the concept of 
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qualitative modeling by replacing qualitative confluences by 
simplified analytic equations which allow exact comparison of 
conflicting influences and the use of known component 
parameters, such as efficiency coefficients. Govinderaj [26] 
describes a qualitative approximation methodology using 
"moderate fidelity simulators". System components are modeled 
using simplified dynamical equations abstracted from continuity 
and compatibility conditions. Biswas [10] describes another 
modeling methodology using analytic equations which approximate 
actual device behavior. 

Even less information is required for causal modeling. 
Causal models, in their simplest form, only describe the causal 
relationships between aberrations of component behavior. 
Component behavior is abstracted into function and the 
functional model merely describes which functions, and therefore 
which components, depend on each other. All that can be said 
about a pump, for example, is that its function is to create a 
pressure increase, whether it performs this function or not, and 
which subsequent function depends on the correct functioning of 
the pump. An extended causal model will enumerate types of 
anomalies of functions and how anomalies in one component cause 
anomalies in the functions dependent on it. In a staged pump 
system, for example, reduced pump performance in the first 
stage will increase pump workload in the second stage. 

Still more detail can be incorporated into a causal model 
if deviations of parameter values are considered instead of 
deviations in overall function. For example, anomalous pressure 
at the input of a pipe will result in anomalous pressure at its 
output. Low input pressure to a pump leads to low output 
pressure unless a controller increases the power driving the 
pump. This detailed causal model approaches the capabilities of 
a qualitative model, except that it describes deviations from a 
norm instead of absolute behavior. Govinderaj 's system [26] also 
reasons about deviations from steady-state but uses quantitative 
equations. He advocates his approach for applications involving 
large complex dynamic systems such as a marine steam power 
plant. 

A most interesting aspect of functional models is the 
possibility to switch between levels of abstraction and relate 
the functioning of a component to the functioning of the 
enclosing module. The intrinsic function of a pump is to expel 
fluid at a pressure higher than at the intake, while in the 
context of the SSME, the function of the pump may be to push 
fuel through the cooling circuits at a high enough rate. 
Sembugamoorthy and Chandrasekaran [27] and Bylander [28] have 
presented an approach to this problem but more needs to be done. 
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2.3 Alternative Diagnostic Methods 


As suggested by the classification scheme for diagnostic 
systems delineated by Milne [12] we will discuss compiled 
knowledge systems in the following, having completed the 
presentation of structural, behavioral, and functional models. 

Abstracting device behavior and function beyond causal 
models leads to "compiled" diagnostic systems which explicitly 
associate symptoms with fault hypotheses. Heuristic, pattern 
matching, or associational systems belong to this category. 
Most commercial expert systems are based on compiled heuristics 
and specialized software tools have been developed to help build 
them. Frequently, heuristics are stored as production rules. 
The validity of a compiled system depends on completeness of the 
rule base and exhaustive enumeration of possible faults. Rules 
can be created by experts or extracted from case data. 

The advantages of heuristic based systems are that they can 
deal with common faults rapidly and economically, that they do 
not need good models of the device, and that the user group is 
more likely to accept a knowledge-based system if they were 
involved in its creation. The disadvantage of expert systems 
based on application-specific heuristics are that they only 
cover explicitly enumerated faults, that they are difficult to 
maintain and extend, and that they apply only to a specific 
application. 

Continuing research on compiled knowledge systems has 
generated approaches to generalize and reuse heuristics from one 
application to another, see, for example, Malin and Lance [29] . 
Generalization of heuristics which are tied to particular 
components requires reversing the symptom-fault heuristic to a 
fault-symptom prediction format. Component models which are to 
produce heuristic rules thus need to facilitate enumerating the 
possible faults of a component and to predict the effects of 
those faults on component behavior. These models differ from 
the models discussed above in that they contain knowledge about 
specific faults and effects of faults. Of course, they are also 
used differently, i.e. to create heuristic rules which embody 
symptom-fault associations. 

2.4 Use of Fault Models 

Fault models, i.e. descriptions of how the behavior of a 
component changes given a fault has occurred, have the potential 
to assist in selecting fault candidates, testing fault 
hypotheses, and refining fault hypotheses. Substantial 
differences in the use of fault models warrants a more detailed 
analysis of the utility of fault models. Some model-based 
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systems, such as GDE, operate totally without resorting to the 
use of fault models. They operate under the assumption that 
hypotheses can be pruned and refined by collecting additional 
data until a unique fault (or set of faults) has been 
determined. 

Fault models may be used to determine if a candidate 
component, in fact, has a failure mode which can account for the 
observed symptoms. This method can be applied in model-based 
systems when several competing hypotheses remain but no further 
data can be collected to discriminate between them. At this 
point some assumptions must be made in order to proceed with the 
diagnosis. Using fault models to eliminate hypotheses implies 
the assumption that the enumerated fault modes are more likely 
to occur than other, as yet unconceived, faults. 

Fault models can also refine a unique hypothesis by 
postulating a particular fault in a component. Generic 
diagnosis, such as the GDE methodology, pinpoints only a 
component, but does not identify how it has failed. If the 
actual fault is of interest, or if the fault is to be localized 
more precisely within the component but no detailed component 
model is available, then fault models can be matched against the 
observed symptom. 

2 . 5 Mixed Paradigm Systems 

Model-based and heuristic-based diagnostic systems each 
have unique advantages and disadvantages as discussed above. To 
incorporate both paradigms into one system could potentially 
combine the strengths of each approach. Establishing smooth 
cooperation between these divergent methods poses some problems, 
however. Model-based systems execute in a sequential, 
algorithmic manner, where hypotheses are first generated, then 
tested, and finally discriminated. Heuristic rule-based systems 
for the most part operate in a goal-driven associational 
fashion. Hypotheses are created one at a time; each is 
evaluated separately using observations or intermediate 
inferences left over from processing a previous hypothesis. 
Hypotheses may be discarded any time the conditions of a rule 
are satisfied by some pattern in the data. 

Typically, systems which incorporate model and 
heuristic-based reasoning alternatively execute two separate 
reasoning mechanisms for each paradigm. For example, Fink [30] 
describes the I DM (integrated diagnostic model) system which 
first executes a heuristic module and then switches to a 
model-based module when the heuristics fail to provide a 
diagnosis. A conversion mechanisms is provided which allows 
sharing of information between the two modules. Another 
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approach, specified by Pazzani and Brindle [31], calls on 
heuristic rules to hypothesize faults and device models to 
confirm or deny those hypotheses. Pflueger [32] mixes 
experiential diagnosis based on associational rules and 
model -based reasoning using a "logic function model" and 
constraint propagation and suspension. Rules are used to 
accelerate recognition of frequent faults and in cases where 
components cannot be adequately modeled. 
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3. DESCRIPTION OF SPACE SHUTTLE MAIN ENGINE SYSTEM 

The Space Shuttle Main Engine (SSME) is a reusable, high 
performance, liquid-propellant rocket engine with variable 
thrust. Figure 1 contains a schematic diagram of the main 
components of the engine. The engine burns liquid oxygen and 
liquid hydrogen at a mixture ratio of 6:1 to produce a sea 
level thrust of 375,000 pounds. The chamber pressure is 
approximately 3000 psia and the SSME is throttleable over a 
range of 65 to 109 percent of rated power level. The engine is 
regarded as a high-performance engine due to the high chamber 
pressure and the use of a staged combustion power cycle. 

In the SSME staged combustion power cycle, the propellants 
are partially burned at low mixture ratio, very high pressure, 
and relatively low temperature in the preburners to produce 
hydrogen- rich gas to power the high-pressure turbopumps. This 
hydrogen-rich steam is then routed to the main injector where it 
is injected along with additional oxidizer and fuel into the 
main combustion chamber. Hydrogen fuel is used to cool all 
combustion devices directly exposed to high-temperature products 
of combustion. An electronic controller automatically performs 
checkout, startup, ma instage, and shutdown operations. 


3 . 1 Major Components 

Key components to the SSME system are four turbopumps, two 
low pressure and two high pressure: 

1) low-pressure fuel turbopump (LDFTP) 

2) low-pressure oxidizer turbopump (LPOTP) 

3) high-pressure fuel turbopump (HPFTP) 

4) high-pressure oxidizer turbopump (HPOTP) 

These pumps are identified in Fig. 1. 

The LPFTP and LPOTP are axial-flow pumps that operate at 
relatively low speeds and provide the pressure increase required 
at the inlets of the respective high-pressure turbopumps. 

The HPFTP is a three-stage, centrifugal-flow pump driven 
directly by a two-stage hot-gas turbine. The HPOTP consists of 
two centrifugal-flow pumps on a common shaft and driven directly 
by a two-stage hot-gas turbine. The main pump supplies oxidizer 
to the main combustion chamber, the LPOTP turbine, and the 
preburner oxidizer pump. The preburner oxidizer pump raises the 
pressure of the oxidizer and supplies it to the fuel and 
oxidizer preburners. 
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Figure 1. Schematic of SSME. 



The hot-gas manifold (HGM) is the structural backbone of 
the SSME engine system in that it supports two preburners, two 
high-pressure pumps, the main injector and the main combustion 
chamber. It interconnects the fuel and oxidizer preburners (FPB 
and OPB) to the main chamber injector. The FPB and OPB generate 
fuel-rich gases that power the HPFTP and HPOTP. 

The main combustion chamber (MCC) is attached to the HGM 
and consists of an internal coolant liner and an external 
structural jacket. The nozzle is bolted to the MCC. 

In addition to the items mentioned above, the SSME key 
components are connected by various interconnects: main 
propellant articulating ducts, fluid interface lines, and 
component interconnects. These interconnects contain important 
valves such as the main oxidizer valve (MOV) , main fuel valve 
(MFV) , fuel preburner oxidizer valve (FPOV) , oxidizer preburner 
oxidizer valve (OPOV) , and the chamber coolant valve (CCV) . 

For simplicity, the SSME system considered in this work has 
been simplified by omitting the pogo suppression system, the 
propellant tank pressurization system and certain minor 
propellant ductwork - none of these omissions change the basic 
operation of the system. The simplified system is illustrated 
in Fig. 2. 

For the purposes of system modeling, these components need 
more definition. This definition is provided in Section 4.3. 

3 . 2 Interconnect ivitv 

The interconnectivity of the SSME system key components is 
illustrated schematically in Fig. 2. As can be seen the 
turbines and pumps are directly (mechanically) connected, the 
preburners are directly connected to the respective turbines and 
all other components are connected by propellant ducts. 
Precise statements of interconnectivity are described in Section 
4.4. 


3 . 3 Test Data 

Test data from SSME engine firings are recorded as analog 
signals on magnetic tape and later digitized and stored in files 
on hard disks. The data is in the form of time-histories of 
individual sensor output. The EDIS system accesses these 
digitized data files and performs diagnostic functions by 
comparing data values with expected or calculated values. 

Simple temperature, pressure, and shaft speed 
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time-histories from a typical SSME static firing are illustrated 
in Figures 3, 4, and 5. As can be seen, the data contains 
engine start, mainstage, and shutdown phases. Current EDIS 
operation is restricted to consideration of only the mainstage 
of operation. 
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Figure 3. Temperature History During SSME Firing 
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Figure 4. Pressure History During SSME Firing. 
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Figure 5. Shaft Speed During SSME Firing. 
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4. ENGINE DATA INTERPRETATION SYSTEM (EDIS) DESCRIPTION 

4 . 1 Diagnostic Paradigm 

Goals - Selection of a diagnostic paradigm to be integrated 
into the SSME data review process was constrained by a number of 
goals specified at the outset of the project. The finished 
system was to contain generic propulsion and engine operation 
knowledge and to be configurable for various engines and engine 
variations. The SSME itself is undergoing continual 
modifications which must be accounted for by a diagnostic 
system. The diagnostic operation should be easy to modify and 
upgrade in order to provide a stable platform for future 
enhancements. The system should be able to explain its 
reasoning steps in terms and formats familiar to the user. The 
reasoning process should be controlled by an ejqplicit strategy 
module which affords the user the opportunity to change and 
direct diagnostic reasoning. The system should be able to use 
available numeric engine models and records of past engine 
performance. The diagnostic paradigm developed in this work 
addresses these issues. It will be described below. 

Specific Considerations - Diagnosis of the SSME differs in 
some important aspects from diagnosis of devices as commonly 
reported in the literature. The SSME is a complex system, and 
therefore difficult to model, not because it has a large number 
of components but because the thermodynamic processes are 
non-linear and coupled, and because some of its parameters are 
regulated by an engine controller. The controller will not 
allow deviations of controlled parameters within the limits of 
its capability. Deviations will show up at the actuated 
variables instead. 

Testing an SSME is very complicated, labor-intensive, and 
expensive. It is not possible to repeat a test to get noire or 
different measurements due to the limited life of individual 
components and the unique conditions surrounding each test. The 
question of selecting additional points to probe is mute. To 
offset the lack of additional measurements an unusually large 
number of parameters are measured during each test. In many 
cases redundant instrumentation measures the same parameter. 
Access to an almost complete set of test data is beneficial. 
Nevertheless, the amount of data recorded during one test make's 
it difficult for the reviewers to select relevant information 
from the bulk of data. 

Due to the lack of a simple and accurate engine model, the 
data review process is largely based on comparing test data to 
records of previous tests, to average and normal variation data, 
and to absolute limit data. These comparison data are stored in 
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databases and can be plotted for visual comparison during the 
review process. Some of the historic data records were measured 
on engines which turned out to be defective. These records can 
be compared to new records when the same fault is suspected to 
be present in the current test. Available numeric engine models 
are executed in order to quantitatively characterize engine and 
turbomachinery performance and sometimes to predict effects of 
faults. Fault prediction is limited to small fluid and gas 
leaks and pipe obstructions. 

Diagnosis is performed in the context of the data review 
process only, i.e. off-line. Real-time operation of the 
diagnostic system is not envisioned at this time, especially 
since interaction with review personnel is required. Ways of 
adapting the diagnostic paradigm to on-line monitoring and 
diagnosis may be investigated later. 

Design - The SSME review process is composed of several 
tasks. First, test data are inspected to detect data anomalies. 
Anomalies are then characterized according to whether they are 
value, i.e. static, or dynamic deviations, whether they occur 
during start-up, main-stage, or shutdown, and whether they are 
consistent or erratic. Anomaly explanation is based on the 
experience that anomalies can be caused by sensor problems, data 
manipulation and presentation artifacts, and by actual 
engine-related causes. The SSME will produce slightly different 
data at every test because of random variations, because of wear 
in the turbo-machinery, and because of replaced turbo-machinery. 
Actual engine problems can be related to turbo-machinery alone 
or to faults somewhere else in the engine. Finally, engine 
behavior may deviate from the norm because of changes in 
throttle control demanded by special test objectives. 

A knowledge -based system to support the review process must 
take all these real and pseudo-faults into account when 
interpreting data anomalies. Our design calls for the following 
steps. Anomaly detection, verification, and fault diagnosis. 
Anomaly verification eliminates deviations due to test 
objectives, data manipulation, random variations, and sensor 
problems from consideration. Fault diagnosis finds 
turbo-machinery and general engine faults. At this point only 
fault diagnosis has been developed in detail. The diagnostic 
method is described in the next section. 

The above described method of first classifying anomalies 
into one of several categories is an example of diagnosis by 
successive refinement or focusing. Chandrasekaran [33] has 
identified hierarchical, successive refinement as one of a few 
generic reasoning methods. Hierarchical diagnosis (or problem 
solving in general) is commonly used by human experts [34] 
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because it reduces the complexity of diagnostic search. The 
diagnostic method loses some generality, however, when anomaly 
explanations are separated into classes. Constraint propagation 
techniques, for example, can find multiple faults only under the 
condition that a single complete model exists which fully 
describes the system to be diagnosed. Unfortunately, it is hard 
to imagine a model which can combine physical descriptions, 
control variations, and data manipulation procedures. Sensor 
behavior could be incorporated fairly easily, though. 

Method - The diagnostic procedure is compartmentalized into 
hypothesis generation, testing, and discrimination. The 
architecture of the diagnostic system, see Section 4.2, provides 
means to explicitly represent anomalies, hypotheses, and 
decisions about hypotheses, as well as means to dynamically 
schedule knowledge sources. These architectural features make 
it possible to combine and coordinate various diagnostic 
paradigms. For example, hypotheses can be created by a 
constraint propagation mechanism as in GDE [a] , by heuristic 
rules contributed by a human expert, or by rules induced from 
exhaustive fault simulation. In every situation the most 
appropriate paradigm can be chosen in order to maximize system 
performance. In addition, hypotheses can be formulated and 
examined with the help of numeric engine models and records of 
previous test data. 

Constraint-based diagnosis based on a causal model of the 
SSME is the primary method which ensures maximum fault coverage. 
In Section 4.3 we will present the constraint propagation 
mechanism and the qualitative model in detail. Heuristic rules 
acquired from human experts are included to serve two purposes. 
Rules are able to identify common faults quickly and they can be 
applied to discriminate between hypotheses when not enough data 
are available to disambiguate the diagnosis. Moreover, we plan 
to incorporate a robust rule acquisition mechanism which will 
allow experts and prospective users to add heuristics to the 
system. This will, we hope, increase acceptance of the system 
for routine use. 

Hypothesis Generation - Constraint propagation in the 
qualitative model and heuristic rules generate hypotheses. 
Hypotheses created by constraint propagation are consistent with 
the observed symptoms but not necessarily with the expected 
fault modes of components. Hypotheses constructed by heuristic 
rules may not be consistent with the symptoms or the fault 
modes. Their validity depends totally on the quality, i.e. 
correctness, consistency, and completeness, of the expertise 
incorporated in the rules. Quality has to be assured during the 
knowledge acquisition process. 
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Hypothesis Testing - The validity of hypotheses created by 
constraint propagation depends on the accuracy of the 
qualitative model. Some hypotheses produced by a model of 
little detail can be eliminated when a more detailed model is 
consulted. For example, hypotheses generated from a model based 
on qualitative relations only, may be tested with the help of a 
simplified quantitative model which characterizes anomalies and 
behavior more accurately. Chances of eliminating valid 
hypotheses are negligible unless the model is overly simplified. 
Tests may also be based on physical plausibility, e.g. 
conservation laws. For example, a component cannot exhibit a 
fault mode where energy is created. 

Hypothesis Discrimination - When several hypotheses remain 
after testing, hypotheses are ranked according to plausibility. 
Fault plausibility is increased by agreement with numeric fault 
simulations, by correlation with predetermined fault models, by 
agreement with previous anomaly - fault observations, and by 
observed frequency of occurrence of the fault. The final result 
of diagnosis is a ranked list of plausible fault hypotheses 
which could not be ruled out. In general, no single unique 
fault can be determined. 


4 . 2 Architecture 

EDIS is built upon a modular blackboard architecture. EDIS 
system modules are defined and implemented independently from 
each other, lending flexibility to system development, 
enhancement, and maintenance. The EDIS system is modularized 
according to functional criteria which do not necessarily 
reflect physical modularization. Functional modularization 
facilitates intelligent scheduling and allows the user to 
actively participate in the problem solving process via a 
mixed-initiative dialogue. Major functional units include data 
retrieval, sensor validation, diagnosis, and user interfacing. 
Functional units may be decomposed into smaller tasks. The 
diagnostic process, for example, is subdivided into anomaly 
detection and classification, hypotheses generation, hypotheses 
testing, and hypotheses discrimination. All of these modules 
operate on the whole SSME model because behavior of SSME 
components cannot, in general, be evaluated in isolation. 

All EDIS modules share a common explicit structural and 
functional model of the SSME. More specialized models, such as 
turbo machinery models and combustion process models, for 
example, may reside within individual modules. Reasoning based 
on these special purpose models is separate from the basic 
diagnostic process. A similar separation has been observed to 
exist in the current data review process where turbo machinery 
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and other specialists are generally only consulted to verify 
hypotheses created from analysis of engine performance. 

The blackboard serves at the same time as central 
inter-module communication medium and as repository for system 
state information. The blackboard is the common communication 
medium through which all modules exchange information. Modules 
encapsulate reasonably self-contained functions so that the need 
for inter-module communication is minimized. Anomalies, 
hypotheses, and other important items are stored explicitly on 
the blackboard. There they can be read by other modules and the 
blackboard serves as a communication medium. At the same time, 
however, the information stored on the blackboard represents the 
state of the analysis process since findings, hypotheses, and 
also tasks (previously executed as well as scheduled ones) can 
be found there. Normally, information is never deleted from the 
blackboard. Instead, items are marked as obsolete when 
necessary. Obsolescence decision time and agent are recorded 
with the item. Decisions about data validity are thus made 
explicit and reversible. 

A complete, explicit account of system state makes in-depth 
explanation of system actions and reasoning possible. 
Explanations can be prepared according to current system goals 
and against the background of previous decisions and events. 
Explanation becomes independent from specific reasoning 
implementations, such as rules, and even reasoning mechanisms. 
Conclusions, decisions, and supporting information can be 
examined instead of rules. 

Module functions can be classified into control, diagnostic 
reasoning, data interface, and user interface functions. A 
strategy module controls the scheduling of all other modules. 
It is scheduled automatically when the EDIS system is first 
initialized. The strategy module creates tasks on the 
blackboard which identify the modules (also called knowledge 
sources in the context of blackboard management) to be executed. 
The strategy module can schedule itself repeatedly to monitor 
the progress of data analysis and to possibly reschedule tasks. 
User interface tasks present data to users and ask for input. 
Both textual and graphical displays are available on the PC 
platform. For example, the user completes an input form to 
supply test and data file names and the type of comparison data 
used for anomaly detection. In later stages of reasoning 
anomalies, hypotheses, and inferences can be presented and 
verified or rejected by the user. A graphical representation of 
SSME structure helps visualize hypothesized causal relations 
between symptoms and faults. Specialized interface modules can 
be provided to access any of the various data bases which 
contain perf romance, configuration, and fault data. 
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The blackboard data structures mirror the object-oriented 
data structures of the reasoning modules. The blackboard 
contains data in the form of classes, class members, attributes, 
and attribute values. Classes define structure and attributes of 
their members. Attributes have names and values. Values are 
stored as character strings in order to be compatible with the 
knowledge engineering tool used (KES) . Blackboard data 
structures are isomorph to KES class definitions. The 
blackboard assumes, however, that data are correctly formatted, 
i.e. no syntax checking is performed. 

Blackboard data reflect the functional diversity of the 
system modules and can be classified into control, model, and 
reasoning data and parameter or input values. Control 
information constitutes the link between modules (especially the 
strategy module) and the system framework. Control information 
is interpreted by the scheduler and dispatcher which generate 
the actual flow of program execution. Members of the classes 
TASK and KNOWLEDGE SOURCE represent control information on the 
blackboard. A task is characterized by the attributes name, 
priority, and knowledge source. Task priority guides the 
scheduling mechanism in selecting the next task to execute. The 
specified knowledge source indicates 

4 . 3 Domain Modeling 

Following Biswas [10], the structural schematic of the SSME 
system is described in terms of primitive components, complex 
components, component categories, a set of interconnections, and 
fundamental processes. Table 1 contains a list of primitive 
components for the SSME system and Table 2 the primitive 
component categories. All turbopumps are considered to be 
complex components consisting of turbine and pump primitive 
components. Note that a distinction is made betwen gas-turbine 
and hydraulic-turbine turbopumps - different thermodynamic 
relations are used to describe the behavior of gases and liquids 
in turbine processes. 

SSME structure is modeled as a collection of interconnected 
instances of components, each characterized by a generic 
thermodynamic process, see Section 4.4. SSME behavior is 
modeled in terms of deviations of engine parameter values from 
normal values. Sets of normal values have been collected at 
NASA MSFC for each operating region and are available in a data 
base. Deviations of parameter values can be propagated through 
the component network using component behavior models. 
Component behavior is modeled using constraints at two levels of 
specificity. A purely qualitative model is valid for any 
component of a given type, e.g. pump, pipe, etc. It relates 
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TABLE 1. LIST OF PRIMITIVE COMPONENTS 


NAME 


DESCRIPTION 


LPFTT 

LPFPP 

LPOTT 

LPOTP 

HPFTT 

HPFTP 

HPOTT 

HPOTP 

FPB 

OPB 

MCC 

MFV 

MOV 

FPOV 

OPOV 

CCV 

MCON 

NOZ 

F101 

F102 

F103 


Low Pressure Fuel Turbopump Turbine 

Low Pressure Fuel Turbopump Pump 

Low Pressure Oxidizer Turbopump Turbine 

Low Pressure Oxidizer Turbopump Pump 

High Pressure Fuel Turbopump Turbine 

High Pressure Fuel Turbopump Pump 

High Pressure Oxidizer Turbopump Turbine 

High Pressure Oxidizer Turbopump Pump 

Fuel Preburner 

Oxidizer Preburner 

Main Cumbustion Chamber 

Main Fuel Valve 

Main Oxidizer Valve 

Fuel Preburner Oxidizer Valve 

Oxidizer Preburner Oxidizer Valve 

Chamber Coolant Valve 

Controller 

Nozzle 

Fuel Duct 101 
Fuel Duct 102 
Fuel Duct 103 


Fill 

0201 

0202 


Fuel Duct 111 
Oxidizer Duct 201 
Oxidizer Duct 202 


0208 

HY101 - 

HY102 - 


HYlll - 
0X201 - 


Oxidizer 

Hydrogen 

Hydrogen 


Duct 203 
Fluid 101 
Fluid 102 


Fluid 111 


Hydrogen 
Oxygen Fluid 201 


0X208 - Oxygen Fluid 208 



TABLE 2. PRIMITIVE 

COMPONENT 

CATEGORIES 

a) 

Gas Turbines 

f) 

Valves 

b) 

Hydraulic Turbines 

g) 

Preburners 

c) 

Pumps 

h) 

Combustion Chambers 

d) 

Ducts 

i) 

Controllers 

e) 

Fluids 

j) 

Nozzles 
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qualitative deviations of input parameters to qualitative 
deviations of output parameters assuming the component is 
functioning correctly. Simplified quantitative models can be 
made available for the components of a particular system. 
Design parameters and empirically determined coefficients have 
to be incorporated into the quantitative equations. The 
quantitative model can determine and process relative strengths 
of influences. 

In some cases local propagation results are indeterminate 
using either model. Indeterminacy is inevitable when parameter 
values depend on boundary conditions which can only be derived 
from an analysis of the complete system. Thermodynamic systems 
rarely exhibit unidirectional causality at the parameter level, 
i.e. parameter values almost always depend on the behavior of 
neighboring components and on boundary conditions. Also, 
component behavior is described by at least two or more 
interacting parameters, e.g. fluid or gas pressure, velocity, 
and temperature. When a constraint cannot be verified or used 
due to lack of data, " the assumption is made that no or the 
smallest possible deviation from normal behavior has occurred. 
Assumptions are recorded and verified or rejected when new data 
become available, for example, during analysis of another 
component . 

Fundamental constraints which describe correct component 
behavior are derived from energy conservation laws. When a 
constraint does not mention measurable parameters explicitly, 
normative constraints are added which hold under the assumption 
that the quantities on both sides of the fundamental constraint 
are constant. Normative constraints do not determine correct 
behavior but relate measurable parameters to fundamental 
constraints. They correspond to a more detailed model of the 
component in terms of thermodynamic processes. They organize the 
prediction/verification process so that behavior constraints can 
be verified incrementally and that necessary assumptions become 
evident . 

Qualitative Behavior Model — Qualitative models consist of 
qualitative fundamental constraints, normative constraints, and 
auxiliary qualitative relations between quantities in different 
constraints. Constraints and relations determine existence and 
direction of the deviation in a quantity based on a deviation in 
a related quantity. Conceivably, deviations could additionally 
be characterized by qualitative statements of relative size but 
the current design does not use size. Constraints and relations 
are expressed in the same syntax. The general form of a 
qualitative statement is "Quantity-1 Relational-Operator 
Quantity-2". The two relational operators are "is proportional 
to" (p) and "is inversely proportional to" (ip) . A quantity is 
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either a state parameter of the fluid or gas, such as pressure, 
a derived parameter, such as pressure difference, or an explicit 
measure of energy. 

The semantics of fundamental and normative constraints and 
of auxiliary relations differ. A fundamental constraint 
captures an energy balance which must hold when the component is 
operating correctly. Faults are assumed to introduce additional 
losses, in general. Normative constraints must hold as long as 
the quantity they depend on remains constant. Auxiliary 
relations describe how a change in the presumably constant 
quantity (called a '•pseudo-constant" ) are reflected in the 
quantities of the normative constraint. An auxiliary relation 
thus couples a normative relation to a fundamental relation via 
its pseudo-constant quantity. Normative constraints may be 
coupled to a fundamental constraint through a chain of other 
normative constraints in order to deal with more complex cases. 

For example, the behavior of a pipe is characterized by the 
single fundamental constraint CPI: "Pressure-Difference p 
Velocity", meaning that the difference in fluid pressure 
measured at both ends of the pipe is proportional to the 
velocity of the fluid. This constraint was derived from the 
fluid energy balance neglecting possible differences in height 
and diameter of the pipe ends. The pipe has one normative 
constraint CP2 : "In-Pressure p Out-Pressure" which holds (at 
least) as long as the pseudo-constant "Pressure-Difference" 
remains constant. One can observe that the normative constraint 
captures a superficial rule-of-thumb analysis of pipe behavior. 
Auxiliary relations are applied when the pseudo-constant has (or 
is suspected to have) changed and its changes have to be 
related to changes in the parameters of the normative 
constraint. In the example the auxiliary relations are 
"In-Pressure p Pressure-Difference" and "Out-Pressure ip 
Pressure-Difference", signifying that the pressure difference 
decreases with rising outflow pressure and decreasing inflow 
pressure. 

The constraints associated with a pump are more complicated 
because energy is added to the system. In the case of the SSME 
energy is provided to each pump by its associated turbine. 
There are two fundamental constraints, one describing the 
transfer of mechanical energy from the outside (the pump shaft) 
to the fluid and one describing the transformation of fluid 
energy into a pressure difference. The fundamental constraints 
are CU1: "Mechanical -Power p E-V-Fluid" (E-V-Fluid refers to the 
fluid energy-velocity product) and CU2: "Fluid-Energy p 
Pressure-Difference". Constraint CU2 shares normative 
constraint and auxiliary equations with constraint CPI described 
above in the context of the pipe model. Constraint CU1 has two 
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normative constraints associated with it, CU3 : "Fluid-Energy ip 
Velocity" related to pseudo-constant "E-V-Fluid" and CU4: 
"Torque ip Shaft-Speed" related to pseudo-constant 
"Mechanical-Power". Constraints for other components are defined 
in a similar manner. 

Simplified Quantitative Behavior Model - Simplified 
quantitative models have the same general structure as 
qualitative models. Fundamental equations express energy 
balances and normative equations define how a quantity (the 
associated pseudo— constant) in a fundamental equation can be 
determined from component parameters. Normative equations thus 
perform the function of both qualitative normative constraints 
and qualitative auxiliary relations. Therefore, auxiliary 
relations are not needed in the quantitative model. Constraints 
are expressed as analytic equations between parameters. 

Simplified quantitative equations, i.e. constraints, are 
derived from exact thermodynamic equations neglecting as many 
terms as possible and performing linearization since the models 
describe deviations from the norm only. Equations are 
conditioned on a particular target system using application 
specific coefficients. Numeric coefficients can be determined 
from design specifications and from analysis of previous system 
performance. Some coefficients describe invariant properties of 
components, such as the friction coefficient of a pipe and 
should always remain constant. Other coefficients are variable, 
such as the efficiency of a turbopump which may change from one 
test to another. Limits on variation are imposed on non-constant 
coefficients instead of testing them against a single given 
value. 

Reasoning With Models - The propagation process through the 
SSME model raises different issues as compared to a situation 
where few data are known to begin with. Propagation does not 
have to proceed across known values. Therefore the component 
network disintegrates into small subnets isolated by locations 
with known parameter values which can be analyzed individually. 
In fact, the decisions not to look beyond known values combined 
with not including conflicts based on two propagated values are 
equivalent to considering only minimal conflicts in GDE. There 
are some cases, however, where this strategy misses the real 
cause of the observed symptom, for example, when a component 
fails due to a fault at its input but masks the original fault. 
Only the secondary fault will be detected by constraint based 
reasoning. Currently, we are ignoring such induced secondary 
faults. 

The goal of the reasoning process is to find which 
components could be responsible for an anomalous parameter 
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value. Following the example of GDE, conflicts are generated 
which contain components at least one of which must be faulty. 
Fault hypotheses are then created such that all conflicts are 
explained. In EDIS conflicts may not accurately reflect the 
status of the SSME because of modeling inaccuracies and 
indeterminacies. EDIS will rather post too many conflicts than 
too few. In GDE components which contribute to a prediction are 
collected while the prediction is being generated, i.e. during 
value propagation. Components encountered during propagation 
are responsible for generating the correct value. EDIS does not 
propagate values to predict normal values or to find symptoms. 
Instead, components responsible for symptoms are found after the 
symptoms, i.e. the anomalous data readings, have been 
identified. 

The reasoning process uses information stored in component 
models to predict parameter deviations and to verify that a 
given set of values conforms to the behavior constraints of the 
relevant components. Input and output are not distinguished 
since constraints are non-directional . Normal behavior is 
tacitly assumed. Unknown parameter values or quantities in 
constraints are assumed to be nominal but such assumptions are 
made explicit. Note that propagation of normal values is 
unnecessary in a behavior model describing only deviations. 
Propagation would only conclude that inferred parameter values 
are also normal, which is assumed anyway. This is a 
simplification compared to the generic method using quantitative 
constraints as exemplified by GDE, but it is only useful if 
normal values for all important parameters are available. 

When symptoms are present, EDIS tries to generate all 
possible consistent situations which can account for the 
symptoms. EDIS generates "scenarios" which indicate measured 
and presumed anomalous parameters and those components which are 
presumed faulty. Scenarios are derived from constraint models. 
Each component which lies in the casual path leading from a 
correct value to an anomaly is examined. If enough data are 
available, all its fundamental constraints can be verified and 
the component can be judged good or faulty. In general this is 
not possible. 

If only one side of a fundamental constraint is known, an 
inference can be made about the other quantity. If the first 
quantity is normal then the second quantity must also be normal 
unless the component is faulty. A conflict will arise if the 
second quantity later turns out to be anomalous. This conflict 
simply states that the component is faulty since one of its 
fundamental constraints is violated. If, however, the first, 
i.e. the known, quantity is anomalous then the component is 
either faulty or the second quantity is corrupted by another 
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component or both. A binary conflict between the component 
being faulty and the quantity being corrupted arises. 

If none of the quantities in a fundamental constraint are 
known, i.e. its normative constraints cannot be evaluated 
because of lack of data, propagation from neighboring components 
is used to derive possible scenarios. If the neighboring 
component has a binary conflict, then both possibilities are 
considered and, possibly, new conflicts are created by fusing 
local data with propagated data. When propagation leads to 
inconsistencies the scenario is impossible. 

Propagation is also used in the previous case, i.e. when 
one side of a fundamental constraint is known, in order to 
examine the validity of scenarios. At the end of analysis one, 
several, or no scenarios may exist. If none survives our method 
has failed. We do not think that this is likely, since no 
particular fault behaviors are assumed. Faults only manifest 
themselves as violated constraints. If exactly one scenario is 
generated, it contains^ the component or components which are 
faulty. If several scenarios survive propagation and testing, 
EDIS or the user have to make a choice. At this point specific 
fault modes or behaviors may be assumed or simply the number of 
faults can be minimized, or fault probabilities of components 
can be utilized to discriminate between fault hypotheses. 

Currently, the failure propagation mechanism is implemented 
using reduced detail, i.e. only anomalies in general are 
propagated instead of detailed information about size and 
direction of particular parameter deviations. Conflicts are 
generated by collecting all components encapsulated between two 
or more correct readings which exhibit at least one anomalous 
parameter value. Such a method which does not use predictive 
models yields too many candidate solutions, but the correct 
solution, i.e. the component which is responsible for the 
anomaly, is guaranteed to be among the candidates. At this time 
candidate (or hypothesis) discrimination proceeds under a single 
fault assumption. Hypotheses which can explain all anomalies 
are located by tracing "backwards" through the component 
structure until a root cause is identified. For simplification 
the algorithm assumes directional causal relations. Simple 
common faults, such as turbine problems, can be found using this 
technique. 


4.4 Interconnectivity, Functionality, and Processes 

Interconnections are determined when the component is 
instantiated as part of a specific device or system. Primitive 
components are grouped in categories for purposes of 
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organization and to get a better understanding of the domain. 
The SSME primitive components are grouped in categories in Table 
3. The interconnections between the components are illustrated 
graphically in Fig. 7- . As can be seen the SSME system is 
modeled as interconnected complex and primitive components. 

Functionality of a primitive component is defined in terms 
of one or more fundamental processes - fundamental statements 
which describe relations among primitive parameters. Parameters 
describe the state of an object. For strict qualitative 
modeling, parameters take on discrete values such as "high", 
"medium”, and "low". The current prototype of the EDIS domain 
uses analytic equations to describe processes to avoid any 
indeterminacy . 

As described above, processes are fundamental statements 
which describe relations among primitive parameters. The seven 
processes currently defined in the prototype EDIS system are: 

1) pGas Turbine 

2) pHydraulic Turbine 

3 ) pTurbopumps 

4 ) pTransmit 

5) pDuct 

6) pValve 

7 ) pPreburner 

The simulation methodology used to derive both deviant and 
normal behavior is described in Section 5. 
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TABLE 3. GROUPING OF PRIMITIVE COMPONENTS INTO CATEGORIES 


Gas Turbines Hydraulic Turbines DUCTS FLUIDS 


LPFTT 

LPOTT 

F101 

HY101 

HPFTT 


F102 

HY102 

HPOTT 


F103 

HY103 



F104 

HY104 

Pumps 

Valves 

F105 

HY105 



F106 

HY106 

LPFTP 

MFV 

F107 

HY107 

LPOTP 

MOV 

F108 

HY108 

HPFTP 

FPOV 

F109 

HY109 

HPOTP 

OPOV 

F110 

HY110 


CCV 

Fill 

HY111 



0201 

0X201 

Combustion 

Chambers 

0202 

0X202 



0203 

0X203 

MCC 


0204 

0X204 



0205 

0X205 

Controllers 

Nozzles 

0207 

0X2 07 

MCON 

NOZ 




Preburners 


OPB 

FPB 
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5. IMPLEMENTATION 


5.1 Shell 

At the beginning of the project several expert system shell 
products were evaluated. Important selection criteria included 
power of representation and inference mechanisms, ease of 
creating a custom user interface, portability between various 
hardware platforms, and ease of integration with existing and 
future software components. Shells which contained support for 
the object-oriented paradigm were preferred. The selected shell 
also had to run on a personal computer. Our evaluation ranked 
NEXPERT -Object first and KES second. However, due to budget 
constraints we selected KES. KES provides backward chaining 
rules, data driven demons, and class/member (object-oriented) 
data representations. In addition we purchased a subroutine 
package from Quinn-Curt is (QC) which contains support for 
mathematical functions and graphical data presentation. The QC 
routines were integrated with KES and provide the user interface 
framework. KES itself was embedded into a C main program which 
manages the blackboard and dispatches the KES modules. 
Embedding KES allows the system designer to develop and test 
EDIS modules as stand-alone KES applications first and 
subsequently integrate them into EDIS. Modules can also be 
written in C, but C modules have to implement blackboard 
communication explicitly. 

KES is currently being updated from version 2.5 to version 
3.0. The new version contains an extended window-driven 
developers interface and support for relations between data 
objects. Version 3.0 is available for the Hewlett-Packard 
workstation and is integrated with X Windows. Version 3.0 has 
not yet been released for the PC. 

A listing of the "C Source Code" is contained in Appendix B 
and one for the "KES Code" in Appendix C. 


5.2 Computer Requirements 

We are using KES 3.0 on an HP 9000/319 UNIX workstation and 
KES 2.5 on a Hewlett-Packard QS 16/S personal computer based on 
the Intel 80386SX microprocessor. The PC uses the DOS 3.3 
operating system. KES does not require a 80386-based PC but it 
is recommended. A numeric coprocessor is recommended especially 
to enhance the speed of drawing graphic images. A hard disk 
drive is required and we used at least 640 KBytes of main 
memory. The display routines can be adapted to any graphics 
interface but EGA or VGA is recommended for better results. 
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5 . 3 File Structure 


There are two C header files "comdef.h" and "ssincl.h". 
"comdef.h" contains data definitions and function declarations 
for blackboard communications, "ssincl.h" has to be included in 
every C file to be compiled. It includes all necessary modules. 


The file "ssmain.c" contains the main program, while 
"bbcomm.c" implements the blackboard communication functions, 
"embed. c" contains the callback interface routines for calls 
from the embedded KES system. On the PC "menul.c", "menu2.c", 
and "menu3.c" contain user interface routines. 

On the PC the system can be compiled with the Microsoft C 
compiler using a "Large" memory model and a stack size of 4000. 
Linking must include ssmain (which includes header) , bbcomm, 
embed, the "menu?" user interface files, and the Quinn-Curt is 
files segruah (an adapted version of segraph) , worlddr, asyncxx, 
and hpplot. Care must be taken that the include files for the 
Quinn-Curtis files can be found by the linker. You may need to 
use the "I" option of the linker. If you have added modules 
(knowledge sources) to the system written in C these must also 
be included. 

KES modules must be parsed with the KES compiler. Compiled 
KES modules must reside in the same directory as the executable 
"ssmain.exe". The KES module "straty.kb" has to exist; it 
represents the strategy module which schedules all tasks. Other 
KES modules currently in use are "freadr.kb" which reads 
simulated test and comparison data from files, "anomal.kb" which 
detects and classifies data anomalies, and "diagn2.kb" which 
attempts to find the fault causing the detected anomalies. 
Figure 6 illustrates the class hierarchy used to define the 
engine model. Figure 7 depicts the reasoning model of the 
preliminary qualitative model. 

The existence of both KES and C knowledge sources has to be 
announced to the system. Enter a function call to "initKS" or 
"initKSC" in the file "header. c" similar to the ones there. You 
will also have to make sure that a task is scheduled which uses 
the new knowledge source. To change task scheduling edit and 
re-parse the "straty.kb" KES knowledge base. Make sure that the 
task will correctly identify the knowledge source to use as 
defined in the "header. c" file. There has to be an "EXIT" task 
on the blackboard or the program will never terminate. 

Data files contain configuration and test data. The file 
"gconf.dat" lists the generic configuration, i.e. components and 
interconnections. Data in "sconf.dat" contains the specific 
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configuration, e.g. turbo machinery serial numbers. Data in 
"dvarlm.dat" specify how far parameter values may deviate from 
the comparison data before they are considered anomalous. 
"tdata.dat" and "cdata.dat" contain simulated test and 
comparison data in a format directly readable by the KES 
"freadr.kb" module. On the PC, the user is prompted for these 
last two file names, all other names are hard-coded in module 
"freadr.kb" . 
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Figure 6. EDIS Component Classification. 













Action: Display Definition 

Attribute: ENERGY_CONV_COMP : > Has Coupling Anomaly 
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ENERGY_CONV_COMP: Has Top Anomaly 










Lon: Display Definition 

'ibute: ENERGY_CONV_COMP : > Has Coupling Anomaly 
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Action: Display Definition 

Attribute: ENERGY_CONV_COMP : > Has Coupling Anomaly 
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Action: Display Definition 

Attribute: ENERGY_CONV_COMP : > Has Output Anomaly 




Action: Display Definition 

Attribute: ENERGY_CONV_COMP : > Has Output Anomaly 
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Action: Display Definition 

Attribute: ENERGY_CONV_COMP : > Has Output Anomaly 
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Energy coupling backward propagation 
























6. CASE STUDIES 


During the course of this investigation interviews were 
conducted with various experts on SSME engine diagnostics. 
Several of these interviews are summarized in Appendix C. From 
these interviews, several special cases of anomalous engine 
performance were determined and the logic surrounding the 
diagnosis of these problems investigated. These special cases 
were then developed into a form for inclusion in EDIS. 

6 . 1 Turbomachinery Malfunctions 

Due to the importance of many turbomachinery components in 
the SSME performance, turbomachinery malfunctions are a common 
cause for anomalous engine behavior. 

High Pressure Fuel Turbopump (HPFTP) Static Seal Leak - In 
this case there is a leakage of gas past the static seal into 
the hot gas manifold. This leakage causes a loss in turbine 
power which, in turn, produces the following effects: 

* reduction in turbopump shaft speed 

* reduction in flow rate exiting turbine 

* reduction in turbopump discharge pressure 

The decreased flow rate is sensed by the controller which causes 
the fuel preburner oxidizer valve to open. This, in turn, 
increases the preburner oxidizer flow rate. 

Under these conditions, the turbopump must do more work for 
the same power output and the tubrine discharge temperature goes 
up. If the temperature goes too high, the SSME will shut down. 

Obstruction in Inlet Duct to Low Pressure Fuel Turbopump 
( LPFT ) Turbine - An obstruction in the inlet duct to the LPFT 
turbine by some foreign object (fractured seals, fracture of 
mozzle vane, glass beads, etc.) causes a loss of energy 
available to the turbine. This, is turn, results in decreased 
turbine power and subsequently a: 

* reduction in LPFTP shaft speed 

* reduction in pump output flow rate 

* reduction in pump discharge pressure 

The controller senses the increased HPFTP demand and increases 
the fuel preburner oxidizer flow. The HPFTP can possibly 
cavitate causing excessive turbine discharge temperatures. 

Power Loss in LPFTP Due to Fracture of Stator Vane - As 
before, a loss of LPFTP turbine power causes a: 
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* reduction in pump shaft speed 

* reduction in pump output flow 

* reduction in pump discharge pressure 

The controller senses the increased HPFTP demand and increases 
the fuel preburner oxidizer flow. In the event of cavitation, 
turbine discharge temperature increases. 

6.2 Fuel and Oxidizer Leaks 

Another common source of anomalous SSME firing data are 
fuel and oxidizer leaks in ducts, manifolds, and cooling 
chambers . 

Fuel Leak in the MCC - A drop in the MCC coolant discharge 
pressure suggests a possiable anomaly. A check in the coolant 
discharge temperature reveals a concurrent drop suggesting a 
decreased resistance and increased flow rate through the MCC. 
The LPFT speed is lower than normal due to the decreased MCC 
discharged pressure. The MCC coolant flow rate reveals an 
increased value. These parameters suggest a leak in the MCC 
coolant tubes. 

These anomalies have been investigated and converted into a 
form for inclusion into EDIS. They are only preliminary and 
represent the manner in which EDIS will perform diagnoses. 
Other anomalies and reasoning will be added to EDIS to make it 
more comprehensive. 
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7. DISCUSSION 


We have developed an architecture and a qualitative 
reasoning mechanism for reviewing SSME test data and diagnosing 
SSME faults based on data anomalies. The modular architecture 
developed for EDIS facilitates modular software development and 
coordination of different reasoning paradigms. The fault 
diagnosis methodology presented combines high degrees of fault 
coverage, domain generality, and domain knowledge. Fault 
coverage is achieved through constraint-based behavior models 
and avoidance of fault assumptions. Domain generality is 
derived from using generic component models and separate 
connectivity descriptions. Domain knowledge is represented by 
the component models. Additionally, expert experience is stored 
in heuristic rules. EDIS incorporates and coordinates reasoning 
based on heuristic expert knowledge, qualitative models, and 
quantitative models. 

Relation to Other Work - The architecture of EDIS is a 
variant of the now widely used "blackboard'’ architecture which 
was made famous by the HEARSAY project [35]. The blackboard 
architecture facilitates incremental system development, 
controlled module interaction, and explicit storage of data and 
inference results. The reasoning architecture used by EDIS 
combines qualitative and quantitative reasoning at the 
hypotheses level which affords more seamless integration than 
was possible before. 

Relevant comparable approaches to diagnosing engineering 
devices have been introduced and discussed at the beginning of 
this report. EDIS uses a constraint-based representation for 
device behavior similar to the one proposed by Davis [13] but 
adopts a qualitative formulation for the constraints as 
introduced by de Kleer [24]. EDIS works with models of correct 
behavior only which has been publicized by Davis and de Kleer 
(GDE) [20]. We had to adapt the reasoning mechanisms of GDE for 
the SSME where component models are too weak to propagate values 
unambiguously. Also, EDIS can reason about possible scenarios 
based on incomplete information while GDE is silent when no more 
data can be acquired. EDIS does not resort to pure trial an 
error constraint suspension but uses constraints on parameters 
as guidance. 

Hudlicka and Lessor [36] have developed a problem-solving 
system for simulating and diagnosing aircraft behavior which 
also incorporates and integrates qualitative and quantitative 
reasoning into a causal model of a complex dynamic system. 
Their system requires an explicit causal model which defines 
influences of components on forces and of forces on flight 
characteristics. The causal model is valid for a specific 
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configuration. EDIS attempts to reason from component models 
and interconnectivity information. EDIS can easily be adapted 
to changes in configuration. The option of creating an explicit 
causal model from the component and constraint-based model to 
facilitate diagnosis later may be explored in the future. Their 
causal model is directional and contains no feedback or cycles 
and does not describe component behavior by itself as compared 
to component constraints in EDIS. Their quantitative model, 
like EDIS, uses simplified linearized equations which are 
defined for a number of operating conditions. Diagnosis does not 
start at the detailed level of sensor anomalies used in EDIS but 
when an alarm at system level is received from a separate 
diagnostic system. The problem of dealing with multiple faults 
is therefore simplified because individual fault notices are 
assumed to be received. In short, the approach taken by EDIS 
appears to model systems at a deeper level. 

Sussman and Steele have developed a general framework for 
reasoning with non-directional constraints [37]. Their approach 
uses "equivalence slices" to represent several different views 
of one set of components and avoids solving simultaneous 
symbolic equations. Each view contributes different pieces of 
the final analysis. A slice can also represent concisely the 
behavior of several components and thus support hierarchical 
composition. CONSTRAINTS manipulates exact numeric constraints 
in contrast to EDIS. CONSTRAINTS is based on EL developed by 
Stallman and Sussman [38] which introduced the method of 
"propagation of constraints" to analyze electrical circuits. EL 
dealt with components which display different behaviors in 
different states by assuming states and retracting inferences 
when an assumed state lead to an inconsistency. EL retains 
dependency information to identify the inferences to retract. 
EDIS must find all possible situations, i.e. all possible 
combinations of component states, which are consistent with the 
data. EDIS uses dependency information not to retract facts but 
to assign blame to faulty components. 

De Kleer applied constraint-based reasoning to qualitative 
analysis of physical systems, in particular to electric circuits 
[39]. In his EQUAL, system component behavior is expressed by 
qualitative equations called "confluences". EQUAL, like EDIS, 
reasons about incremental changes from steady-state operating 
points. The EDIS constraint "A p B" is completely equivalent to 
de Kleer's formulation "dA = dB". Both constraints indicate 
that an increase (or decrease) in A will lead to an increase (or 
decrease) in B. EDIS is limited to first order constraints 
while de Kleer' s qualitative calculus includes higher order 
derivatives. EDIS does not mention steady-state constraints 
because it assumes equilibrium unless otherwise indicated. 
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EDIS captures causality in terms of function instead of 
behavior, cmp. EQUAL. Functional causality leads to the 
distinction between fundamental and normative constraints. The 
primary function of a component gives rise to fundamental 
constraints which are only violated in case of a component 
fault, i.e. when component function is compromised. Given a - 
fundamental constraint, the constrained quantities can be 
related to measurable quantities using normative constraints and 
auxiliary relations. Normative constraints in this sense 
"cause" normative constraints. Functional causality is 

non-directional within constraints, however. For example, the 
primary function of a pump is the conversion of mechanical 
energy into fluid energy. A fundamental constraint of the pump 
model expresses energy conservation across this conversion. 
Mechanical power is characterized via torque and radial 
velocity; fluid power is characterized by fluid energy (and thus 
pressure difference) and fluid velocity. The normative 
constraint that torque is inversely proportional to radial 
velocity is caused by the fundamental constraint which forces 
their product to be constant. 

De Kleer also shows how teleological analysis can lead to 
an understanding of the function of individual components with 
respect to the complete device. EDIS incorporates some causal 
information by virtue of the arrangement of constraints and 
pseudo-constants and thus falls in between GDE, which ignores 
causality, and EQUAL, which explicitly models causality. 
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REPORT ( NAS8-36955 , D.O. 58) 

December 14, 1989 
by 

Martin Hofmann 
Thomas Cost 
UAH 

Current Understanding of the Review and Diagnosis Process 
This report documents the current status of the EDIS project. 
Events : 

Mike Whitley and Gary Lyles were unavailable for two weeks in 
December but Mike Whitley arranged a meeting with SSME data 
review experts for us and has left us some documentation. On 
Dec. 8 we were able to meet with Marc Neely and Lewis Maddox to 
discuss the basics of the data review process. We were also 
introduced to Bruce Boulanger and ??? from Martin Marietta who 
support the numeric SSME performance predication and data 
reduction models. We will meet with them again to learn more 
about the numeric SSME models and how they are used in the data 
review and diagnosis task. 

Tasks: 

We have made progress in all three aspects of the Project 
Assessment Task as defined in the Study Orientation Meeting 
Document of November 2, 1989. (1) The review of applicable 

literature is continuing; a partial bibliography is attached. 

(2) SSME propulsion modeling is being addressed in the context of 
the Power Balance Model and the Digital Transient Model. (3) The 
engine diagnosis task was described to us by Marc Neely and we 
have studied documentation provided by Mike and Bruce. 

The following is a summary of our current understanding of the 
data review and diagnostic processes. We will point out where we 
still lack information, and where we see potential for a 
successful expert system application. We would appreciate any 
corrections or improvements you can suggest for us to 
incorporate. In our next session with Marc we will try to 
identify those faults and symptoms which we will incorporate into 
the prototype system. We will study the knowledge which he 
applies specifically in solving the chosen problems and we will 
determine the tools and mechanisms our system will have to employ 
to mimic his reasoning process. 

X. Literature review: a partial bibliography is attached. 

2. Propulsion system Modeling: 

Documents reviewed: 

"SSME Model Analysis Procedure for Ground Test Data 
Review Support" . 

"Procedure for Implementing the Power Balance". 

"Engine and Pump Performance Calculations Used in 
TIP87BAB" by J. Taylor Hooper. 
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"SSME PHASE II Power Balance Average Database", Memo 
3912-P/10-89 by B. Boulanger, Jan. 19, 1989. 


"RSS-8598-1" describing the Space Shuttle Main Engine 
Performance Prediction and Data Reduction Model and its 
usage. 


"Space Shuttle Main Engine", Part Number RS007001, 
Description and Operation, by Rocketdyne, E41000, 
8559-1-1-1, Sept. 1, 1983. 


SSME 

RSS- 


3. Engine Diagnosis 

Data review is based on knowledge of engine configuration, 
modulation of the control inputs as scheduled f< or the tes t, 
expected data, and measured actual data. Diagnosis is base 
knowledge of how the engine works (in normal and fault 
situations), how the engine is controlled, and what behavior to 
expect. Data are analyzed mostly qualitatively and . 

comparatively . Absolute values are 

absolute limits are exceeded (e.g. as defined in the interfac 
control document). For example, the DTM returns only relative 
data. Fault detection is triggered by unexpected 
(relative to the expected levels) of parameters and by phenomena 
in the data, e.g. steps, spikes, undershoot, overshoot, ®tc. 

Data are inspected first for the whole phase and, if a problem 
suspected, in more detail, i.e. a data segment is enlarged. 

Comparison data : 

Digital data are analyzed in three segments: startup, main stage, 
and shutdown. For each phase comparison data are prepared in 
advance, comparison material is derived from severs 
Note: even the control of the engine is f *i rl y cons J®" t '®* bi- 
valve openings, etc. However, the test “J at^fSt 

changes. In one example, it appeared as if the expert at first 
treated an observed deviation as a possibie probiem and he 
explained it subsequently as being the result of . no ""® J a "J r 
control as required by a test objective. Thu *' * n ®*®®f 
generating new specific reference curves for this particular 
test, a nominal reference was used and expectations for 

differences were created mentally. Diff «® n £®® ‘ =“ £® Solute 
as relative changes, reference curves would have to be absolute 

values . 


a) 2 sigma limits compiled from all previous tests. 

b) Data from (one or two) previous tests with a 
similarly configured engine and similar test 
objectives. 

c) Absolute (static or generic) limits from the 
interface control document. 

d) Known changes to the engine configuration. 

e) Test objectives. 
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f) PBM predictions (?) 

The above mentioned sources define expectations for the actual 
data and for normal, possible deviations from the expected data. 
When deviations are observed they may be explained as normal 
engine variations, effects of wear, effects of replacing 
components, effects of other engine changes, effects of changed 
engine control, effects of changed instrumentation, or faults. 
Faults can be instrumentation faults, data faults, and engine 
faults. 

Fault verification ; 

If a fault is suspected three hypotheses are tested in order: 

i) incorrect sensor readings 

ii) incorrect data processing 

iii) engine faults 

i) Sensor problems can be identified through inspection of raw 
sensor data. Often sensors are redundantly implemented and can 
be checked directly against each other. Other times data 
validity can be checked through dependent data at related 
sensors. Sometimes instrumentation experts can help to identify 
or rule out sensor fault modes and fault possibilities, e.g. 
some sensors cannot read negative values. (We will need more 
detailed information on types, location, and operation of 
sensors . ) Also , there may be known sensor problems which can 
explain differences between data. Sensor problems may exist in 
comparison or test data. 

ii) For now we assume correct processing. 

iii) Diagnosis of the engine is necessary, see below. 

Engine diagnosis : 

Starting from a data anomaly the faulty behavior of the engine is 
reconstructed. Then the cause of the faulty behavior has to be 
determined. Faulty behavior can be explained from a qualitative 
understanding/simulation of the corresponding engine parts. 

Causes for faulty behavior are hypothesized by the expert (based 
on experience?). Hypotheses are tested with the help of numeric 
models. For example, the DTM can verify an incomplete ignition 
hypothesis. Note: "incomplete ignition" may be the cause for 
some data anomalies but it represents faulty behavior and not a 
satisfactory diagnosis. However, it is not directly observable 
and "closer" to a physical or functional cause. Numerical models 
ONLY simulate behaviors and behavior interaction; an expert has 
to postulate the underlying defect(s). Therefore, fault 
hypotheses have to be characterized by fault models for the 
responsible component. Fault models translate faults into fault 
behavior. We are told that sometimes no unambiguous explanation 
for a fault behavior can be found. 

In some cases analog data will be requested from the analog data 
review to gain more information about engine behavior m a given 
interval where a problem is suspected. Analog data can identity 
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imbalance in rotors and ball wear, for example. Also, some data 
are available from test stand instrumentation, e.g. total fuel 
and LOX flows. 

Engine decomposition into subsystems : 

In some situations the behavior of only parts of the engine have 
to be considered, for example each turbopump, the fuel and the 
LOX systems. 

Qualitative model 

The expert uses a mental qualitative model of the structure and 
function of engine components and controllers to predict 
behavior. The expert can derive the effects of deviations of one 
parameter on other parameters in qualitative terms. Controllers 
will often mask faults by compensating for their effects. 
Sometimes resulting transients can be observed in the data, other 
times the controllers act too fast. In feedback situations we 
can look for separate additional effects of members of the 
feedback loop. If qualitative simulation cannot identify the 
cause of a problem, it will at least identify all the involved 
processes. The expert can then select the most likely ones. Of 
course, causal relations could be derived which store the fault 
propagation paths generated by the qualitative reasoning process. 

Some important aspects of SSME operation : 

Preburner operating levels are closed-loop controlled via 
oxidizer flow rates through modulation of the preburner oxidizer 
valves. 

The main oxidizer valve, main fuel valve, and chamber coolant 
valve are scheduled as function of the commanded thrust. 

The main oxidizer valve and the fuel preburner oxidizer valves 
are modulated to maintain engine thrust and mixture ration during 
steady state. 

Problems : 

Diagnosis is performed with the help of several cooperating human 
experts, i.e. digital data expert, analog data expert, 
instrumentation expert, numeric model expert. We will 
concentrate on diagnosis using digital data. 

Data show strong random variation and instrument resolution is 
limited. 

Comparison of test data segments against reference data seems 
more important than assumed. It may be necessary to supply 
numerical data comparison algorithms (in addition to current 
preprocessing). In the short term we will work with 
characterizations of the data, e.g. "data show a step at time t", 
" data show 3% undershoot during time interval tl-t2", or data 
deviate from reference by 10% in time interval tl-t2". The user 
will be prompted to perform manual/visual validation by 
inspecting other, related data curves. 

Additional information needed: 
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Possible 


Documentation on SSME instrumentation. 

When are which numerical models run? 

How is the data base of prior failures used? 
Examples of in-run versus between-run problems. 


Possibly some case records of diagnosed faults. 

Possibly training material for novice data review 
personnel . 

Qualitative reasoning about the behavior of the SSME as 
performed by the human expert, e.g. effects of fuel 
leaks. More detail than what has been observed is 
needed. 

A closer look at the diagnosis process, best in the 
context of some relevant fault. 

Direct access to the case data base and numeric models. 
How important'is it to directly access data? Should 
the system simply ask the user to do that manually. 

Computer networking: can a PC communicate with the IBM 
mainframe? 

Expert System support : 

* Selection of reference material, similar to 
intelligent data base management. 

* Generation of inputs and parameters for numerical 
models . 

* Comparison of data: detection of limit violations. In 
the first phase of this project it may be too 
complicated to detect more subtle phenomena in the 
data . 

* Qualitative simulation of SSME behavior with user 
defined aberrations in the data. 

* Fault hypothesis generation from observed faulty 
behavior, based on causal, functional, and structural 
interdependencies. Assistance in verification, 
testing, and discrimination of hypotheses. 
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REPORT (NAS8-36955, D.O. 58) 

January 25, 1990 
by 

Martin Hofmann 
Thomas cost 
UAH 

Support of the Data Review Process Provided by Numeric Engine Models 
Events : 

On January 17, 1990 Tom Cost and Martin Hofmann met with Bruce 
Boulanger and Brian Piekarski from Martin Marietta, who maintain 
the numeric SSME performance predication and data reduction 
models. We learned what types of analysis they perform in 
support of the data review process. 

Knowledge Gathered: 

Martin Marietta : There are two groups from Martin Marietta 
involved in the engine tests. One inspects raw measured data, 
compares these data with data from the previous test (like Marc 
et al.), and archives the data in a data base. An anomalies data 
base is kept for raw measured data. 

The other group (Bruce & Brian) uses averaged data (from 50 
samples per second to one-second averages) for steady-state data 
sections. Transients are ignored. The PBM, too, works with 1- 
second average data, l-second average data are kept in a data 
base on the IBM. ( B&B are supervised by John Butas from NASA.) 

NASA itself (Chris Singer?) maintains a data base of test data 
from which mean and standard deviation values are derived, i.e. 
the "2-sigma H limits. While B&B work on the IBM, the 2-sigma 
data are kept on the Perkin-Elmer . The IBM can be accessed via a 
modem and KERMIT from a PC. 

Use of Models : The engine models (mainly the PBM, also the DTM) 
are used for two main purposes, a) Engine performance 
evaluation: The group from Martin Marietta provides a second 

opinion versus Rocketdyne's evaluation of engine performance 
after each test, b) Support for the data review process as 
performed by Marc Neely et al., i.e. on a system level. (It 
appears that Marc etc., besides evaluating the digital data, also 
coordinate the evaluation of test data by specialists, e.g. 
numeric model specialists, turbo machinery experts, sensor 
experts, analog data specialists, etc.) 

a) Engine performance evaluation: The main goal is to verify 

that the engine hardware is performing adequately. The hardware 
is either being readied for flight or new designs are tested. The 
PBM is run in the "data reduction mode". Results are presented 
in comparison with 3 or 4 previous tests. For example, a flow 
rate at 104% power at steady-state is plotted versus previous 
test results. Some data patterns indicate problems. For 
example, a steady decline in flow rate may indicate a leak, or 
degraded trust may indicate loss of combustion efficiency, 
measurement problems, or may reflect hardware changes. 

Engine components are evaluated separately (mostly pumps) via 
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efficiency factors. Efficiency factors are calculated by varying 
component^parameters until the model predictions approximate the 
measured data. Efficiency factors are used to characterize 
hardware components. Both individual low efficiency as well as 
disparate efficiencies of fuel and LOX pumps ca "J;® a f 
problems. Excessively low efficiency wili manifest itself 1 
other measured parameters, e.g. high pump discharge temps, 
that model-based analysis is not always necessary. For 
subsequent tests the calculated efficiency factors will be 
to predict overall engine performance. Since P«®PS 1 a £® 
interchangeable individual performance histories are kept for 

them. 

b) Data Review Support: Generally no P ret ® at ictors^re* 66 

exceDt for actual flights, but sometimes KF and C2 factors are 
estimated baseSon the last test. KF and C2 calibrate fuel flow 
and mixture ratio measurements . The model can be used to tes 
fault^hypotheses for leaks and flow resistances The model can 
simulate leaks and increased flow resistance and wlXl 

be interpreted as deviations (or "deltas") from the nominal 
oarameters. The deltas will be indicated m a schematic of the 

engine configurations. Also, plots of "^"^.^“^^p^oducld 
versus anomalous values for various power levels may be produced. 

Main Model Parameters: 


INPUT: 

LOX flow rate \ from facility meters 

fuel flow rate / 

calculated thrust . 

ISP chart (specific impulse: thrust/flow rate) 
nominal mixture ratio 

OUTPUT : 


High pressure (HP) turbine discharge temps (2) 
HP turbine pressures 2 > 
HP pump fuel inlet pressure 

LP fuel turbine inlet temp j*' 
preburner chamber pressures (2) 
HP oxidizer pump suction specific speed ( ) 


Tasks Performed: 

We have completed the project assessment phase and are starting 
the project specification phase. 

Possible additional benefits from an expert system: 

The expert system could exercise the numeric models in support of 
2£c Xlly et a . in standard situations without intervention by 
ESiSTSJlStl personnel . This would permit better integration 
and speedier execution of the review process. The expert system 
would thus capture expertise necessary to run the numen g 
models . 
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(include "ssincl.h" 

int i, j,k, 1; 
int success? 

long int v_tine = 0; /* virtual tine */ 

class_ptr blackboard = MOLL; /* define the unique blackboard */ 

int bb size = 0; /* nuiber of classes on the blackboard */ 

nenber_ptr first task; /* bead ptr for task list */ 

nenber_ptr current_task; 

nenber_ptr tenpnen; 

attr_ptr tenp_attr? 

attr_ptr *app; 

KES conand type comandtype? 

KES~attribute_type tenp_KES_attr? 

KESatr seg_type tenp KES attr seq; 

KES~class_type tenp_KES_cIass, tenp_KES_class2; 

KES~nenber_type tenp_KES_nen? 

KES~value_type tenp_KES_value; 

KES_class_value_type tenp_KES_cv? 
int”(*fct_ptr) (); 

nain() 

{ int nax_prio, nun attrs; 

char *t nane, file nane [LINE_LENGTH], tenp_str_arr [ LIHE_LENGTH ] ; 
fifdef HSDOS 

char tenp33 [ LINE_LEHGTH ] ; 
fendif 

char *KS_nane, *KS_fct, *KS_dir, *C_nane, *tenp_str, *class_nane; 
char *attr nane, *nen nane, *tenp str2? 
char KS_iojist[LIHE_LEHGTH], t_str ing [ LIHE_LEHGTH ] ; 
nenber_ptr t nen; 
attr_val_type t_aval; 

current_task = NOLL; 
first task * HULL; 

initialize ( (blackboard ) ; 
fifdef HSDOS 
initialize_vindovs(); 
fendif 

/* basic loop = task dispatcher */ 

/* THIS FIHDS TASKS CW THE BB! */ 

for (;;) { 

/* find task on BB with highest priority */ 

first_task = bb_find_nen( blackboard, "TASK")? /* get first task */ 

current task = first_task? 

nax_prio = atoi(find~attr_sval(current_task, "priority")); 
current_task = current_task->fvd? 
while (current_task != HULL) { 
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teip_attr = find_attr(current_task->attributes, "priority"); 
if (iax_prio < atoi(teip_attr->attr_value.sval)) { 
firsttask = currenttask; 
nax_prio = atoi(teip_attr->attr_value.sval); 

) 

currenttask * current_task->fwd; 

)t 

/* now first_task holds the task with highest priority */ 

/* assuie there alwas is one: there should always be a 
task to run the strategist left on the BB. To exit 
use an explicit EXIT task! */ 

/* Check for EXIT task */ 
tnaie = find_attr_sval(first_task, "task naie"); 
if (strcip(t_naie, "EXIT") == 0) { 
cleanup)); 

exit(O); /************** PROGBAK EXIT ************************/ 

}; 

/* otherwise do task: retrieve KS */ 

/* For KES task: KS load, BBread, KS_execute, BB_write, KS unload */ 

/* For C prograi: run prograi with paraieter pointer. */ 

/* retrieving the KS and task naie */ 
v tiie++; 

KS naie = find attr sval(first_task, "knowledge source"); 

KS fct = find attr sval(first task, "task naie"); 

teiq> iei = find iei(bb_find_iei(blackboard, "KS"), KS_naie); 

if ( strcip ( f ind”attr_sval ( teip_iei , "KS kind"), "KES") == 0) ( 

/* KES knowledge source */ 

strcpy(file_naie, find_attr_sval(teip_iei, "exec file naie")); 
strcat(file naie, EXTEKS); 

#ifdef HP-OX 

printf) "Executing KES task Is using file ls.\n", t naie, file naie); 

#endif 

#ifdef HSDOS 

sprintf(teip33, "Executing KES task Is using file ls.\n", t_naie, file_naie) 
init_iessage_window( ) ; 

display_as_iessage( teip33 ) ; 

/endif 

/* KS load */ 

if (KES Id kb(file_naie, 60000L) != KES_success_c)/* (1 != 1)*/ { 
printf("Cannot~load KES file ts.\n", file_naie); 

) 

else ( 

/* BB read */ 

/* test puts("BB read."); */ 
strcpy(KS_io_list, find_attr_sval(teip_iei, "IK")); 
teipstr = KSiolist; 

while ((teip_str~= strtok(teip_str, " ,")) != MOLL) ( 
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/* now assert all aeabers */ 
t mi = bb_find_iei( blackboard, teapstr); 
while (t_aea != HOLL) { 
classjiaae = t_aeB->class_naae; 

/* execute coaaands like: reassertclass class = class + leiber */ 

teap_KES_class = KES_g_naaed_class( classjiaae); 

KES _parse_ieibers ( teap KES cIass , t ie*- >aeaber_naae , 

KES_false_c, 4teap_KES_cv); 

KES reassertclass (teap KES_class, KES_true_c, 

KES nuirclass_value_c, teap_KES_cv); 

/ifdef HP-OX 

/* test */ puts ( reassertclass j:oa_gen ( cl ass jiaae , t_iea->Beaber jiaae) ) ; 

/endif 

/ifdef HSDOS 

/* test */ display_as_nessage(reassertclass_coa_gen(class_naae, t_ie*->ieiber_naie) ) ; 
/endif 

tenp_attr = taea- attributes; 
while (teap_attr != HOLL) { _ 

teap KES attr = KES g_naaed_atr(teap_KES_class, teap_attr->attr jiaae); 
teap KES aea = KESgjiaaed ieiber ( teip_KES_class , t_iea->aeaber_naae); 
KES_parse_value ( teap_KES_aea , teap_KES_attr, teap jttr->attr jialue.sval , 
iteap_KES_value); 

KES_reassert(teap_KES_aei, teip_KES_attr, teap_KES_value); 
teap_attr = teap_attr->fwd; 

}; 

t iei = t aea->fwd; 

); " 

teap str = HOLL; /* get ready for next call to strtok */ 

); 

/* KS execute etc. */ 

KS dir = find_attr_sval(teap_Bea, "inference direction"); 
if”(strcap(KS _ dir, "forward") == 0) ( 

/ifdef HP-OX 

/* test */ puts(reassert_glob_coa_gen(find_attr_s7al(teap_aea, 

"function"), "true")); 

/endif 

/ifdef HSDOS 

/* test */ display_as_aessage(reassert_glob_coB_gen(find_attr_sval(teap_Bea, 

"function"), "true")); 

/endif 

teap KES attr = KES g naaed_atr(KES_global_class_c, 

f ind_attr_sval ( teap_aea, 

"function")); 

KES _parse_value ( KES_global_aeaber_c , teap_KES_attr, "true", 

4teap_KES value); 

KES reassert (KES global_Beaber_c, teap_KES_attr, teap_KES_value); 

) 

else { 
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fifdef HP-UX 

/* test */ puts ( obtain_co«_gen ( f ind_attr_sval ( teip_iei , "function"))); 
lendif 

/ifdef HSDOS 

/* test */ display as_iessage ( obta in_coi_gen ( f ind_attr_sval ( te«p_iei , "function"))); 
Jendif 

KES obtain atr(KES_global_ieiber_c, 

KES ~g_naied_atr ( K£S_global_class_c , 

find attr sval(teip iei, "function") 

)); " 

)i 

/* BB write */ 

strcpy(KS_io_list, find_attr_sval(teip_iei r "OUT")); 
classjiaie = KS_io_list; 

/* for all classes on the OUT list */ 

while ((class naie = strtok(class_naie, " ,")) != HULL) { 

/* prepare access to attributes (using level 3) */ 
teip_KES_class = KES_g_na*ed_class(class_naie); 

/* now step through all class leibers */ 

for (teap_KES_iei = KES_g_next_«e*ber(teip_KES_class ; 

KES_null_ieiber_c); 
teip KES *ei != KES_null_«eiber_c; 
te«p~KES~iei * KES g next ieiber(teip KES class, 

" ' teip"KES_iei)) ( 

/* create a new C leiber */ 
t_«e* = new_*eiber( ) ; 
strcpy ( t_*ei- >«eiber_naie , 

KES_g_»e«ber_naie( te«p_KES_*e«) ) ; 
t_*ei->attributes = HULL; 
t”«e«->n_attr * 0; 

strcpy ( tnei- >class_na*e , 

KES g_class_naie(KES_g_«eiber_class(teip_KES_iei) ) ) ; 

/* the specific class (not a superclass) */ 
teip_KES_class2 = KES_g_na*ed_class(t_»ei->class_naie); 
teip KES attr seg = KES_g_atrs( teip_KES_class2 ) ; 
nui attrs = KES_g_nui_atrs(teip_KES_attr_seg); 

/* retrieve and'add the attributes */ 
for (i = 1; i <= nui_attrs; ++i) { 
teip_KES attr = KES g_nth_atr(teip_KES_attr_seg, i); 
attr naie = KES g atr’naie ( teip_KES_attr ) ; 
if ( KES_g_atr_status ( teip_KES_iei , teip_KES_attr ) 

== KES known c) { 

teip_str"= KES~d value (teip_KES_iei, teip_KES_attr); 

/* parse the value string! (get only first value!) */ 

/* throw away anything after a "<" character: this 
should be the certainty factor of the first value */ 
strcpy (teip_str_arr, teip_str); 

1 = strcspn j teip_str_arr , "<"); 
teip str_arr[l] = '\0'; 

while ((isalnui(teip_str_arr[strlen(teip_str_arr)-l]) == 0) 
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hi (strlen(teap_str_arr) > 0)) { 
teap_str_arr [ str len ( teip_str_arr ) - 1] = '\0';}; 
while ( ( isalnui ( teip_str _arr [ 0 ] ) == 0) 

H (strlen(teap_str_arr) > 0) ) { 
strcpy(t_string, teap_str_arr+l); 
strcpy ( te*p_str_arr , t_str ing ) ; } ; 
teip_str = teap_str_arr; 

/* now add the attribute */ 
add_attr(i(t_aea->attributes), attrjiaae, teap_str); 
(t_aea->n_attr)++; 

};~ 

); 

/* finally insert on BB */ 
bb insert(&blackboard, classjiane, t_«ei); 

)? 

class naie = NOLL; 

}; 

/* X S unload */ 

KES free kb( ) ; 
fifdef HSDOS 
ClearWindow( ) ; 

/endif 

) 

) 

else { 

/* C prograi */ /* In header. c: define the C function as a KS */ 

/* C prograis can sanipulate the blackboard directly. They 
are responsible for keeping it in correct fonat */ 

printf ( "Executing C task ts.\n", t_naie); 

fctjtr = f ind_attr _gptr ( te«p_iei , "executable function"); 
success * (*fct_ptr)(); 

?; 

/* reset task priority to 0 and set attr "done at" to current "<tiie>" */ 
top_at.tr = f ind_attr( first_task->attributes, "priority"); 
strcpy (teap attr->attr_value.sval, "0"); 

if ((top attr = find attr(first_task->attributes, "done at")) == NOLL) { 
add_attr ( i ( f irst_task->attr ibutes ) , "done at", tiie_gen()); 

) 

else ( /* change tiae of last execution */ 
strcpy(teap attr->attr value. sval, tiae_gen()); 

) 

); 

); 


/* initialization: for each knowledge source add a nenber to 
the knowledge source class on the blackboard; then 
create a task to run the strategist */ 
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void initialize(bbp) bb_ptr bbp; { 
char c_t*p [ HAXMAH ] ; 
int success; 

/* add knowledge sources to BB: include a file with calls to init_KS */ 

t include "header. c" 

/* create task to run strategist */ 
teipiea = new_ieiber(); 

strcpy ( teip_iea->ae*ber_na*e , naae gen ( "task" ) ) ; 
te*p_ie«->n_attr - 4; 
te«p_ae*->attributes = HULL; 
strcpy ( teip_te»- >c lass_na«e , "TASK"); 

/* create attributes */ 

/* attrs: taskjane = "find_task", KS = "strategist", tiie = <now>. 

Thus: there lust be a knowledge source on the BB with naie 
strategist; it lust have a function "find_task"; and the 
KS iust be either an executable C prograi or a parsed knowledge 
base. */ 

sprintf(c_t*p, "li", v_tiie); /* virtual tiie as char string */ 

app = t(teip_iei-> attributes); 

add_attr(app, "tine", c_tip); 

add attrjapp, "priority", "100"); 

add~attr(app, "task naae", "find task"); 

add~attr(app, "knowledge source", "strategist"); 

/* put it on the blackboard */ 

success = bb_insert(bbp, "TASK", teip_*ei); 

switch (success) { 

case -1: printf ( "Cannot initialize the blackboard! \n"); exit(-l); 
break; 

default: printf ("Initialized the blackboard. \n"); 
break; 

) 

/* supply the file naies for the configuration files */ 

/* This could be done in a separate task using user confination/changes */ 
teipiei = new_*eiber(); 

str cpy ( te«p_ie«- > lenber _naie , naie_gen( "file") ) ; 

te«p_ne*->n_attr = 3; 

te«p_»e«->attributes = MULL; 

strcpy ( te«p_*e»->class_naie , "PILE"); 

/* create attributes */ 
app = 4 ( teip_ne«->attributes ) ? 
add attr(app7 "Mane", "sconf.dat"); 
add~attr(app, "Type", "specific configuration"); 
add~attr(app, "Conparison Type", "none"); 

/* put it on the blackboard */ 

success = bb insert(4blackboard, "PILE", te«p_*ei); 
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teipiei = nev_ieiber(); 

strcpy ( teip_iei- > leiber _naie , naie_gen( "f ile") ) ; 

teip_iei->n_attr = 3; 

teip_iei- > attr i butes * MOLL; 

strcpy ( teip_iei- >class_naie , "PILE"); 

/* create attributes */ 
app = 4(teip_iei->attributes); 
add_attr(app, "Haie", "dvarli.dat"); 
add~attr(app, "Type", "variation liiits"); 
add attrjapp, "Coiparison Type", "none"); 

/* put it on the blackboard */ 

success = bb_insert(4blackboard, "FILE", teip_iei); 

teipiei = nev_ieiber(); 
strcpy (teip_iei->ieiber_naie, naie_gen("file") ) ; 
te«p_»e«->n_attr = 3; 
teip_iei->attributes = MOLL; 
strcpy(te«p_iei->class_na«e, "PILE"); _ 

/* create attributes */ 
app = 4 ( teip_iei- >attr ibutes); 
add_attr(app, "Mate", "gconf.dat"); 
add~attr(app, "Type", "general configuration"); 
add~attr(app, "Coiparison Type", "none"); 

/* put it on the blackboard */ 

success = bb_insert( 4blackboard , "FILE", teip_iei); 


); 


/* auxiliary functions */ 

/*********************** / 

/* naie_gen generates a unique naie derived froi a supplied 
string and the virtual tiie. 

*/ 

char *naie_gen(stei) 
char *stei; { 
static char tip[MAXMAM]; 
static long int tag; 
sprintf(t^), "Isli", stei, tag++); 
return tip; 

); 


/* tiiegen generates a string represntation froi the global integer tiie */ 
char *tiie_gen( ) { 
static char tip[MAXMAM|; 
sprintf(tip, "li", v tiie); 
return tip; 

); 
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void init_KS(bbp, naie, fct, dir, exec, kind, in, out) 

bb_ptr bbp? char ‘naie, *fct, *dir, *exec, ‘kind, ‘in, ‘out; { 
teipiei = new_ieiber( ) ; 
strcpy ( teip_iei->ieiber_naie , naie ) ; 
teip_iei->n_attr = 6; 
teipiei->attributes = NOLL; 
strcpy ( teip_iei- >class_naie , "KS" ) ; 
app = S ( teip_iei-> attributes ) ; 
add attr(appl "function", fct); 

/* "function" and "inference direction" specify how to run 
a KES iodule: if direction=forvard then 'assert function-true , 
if direction=backward then 'obtain function' . 


*/ _ . 

/* only one function per KS at this point */ 

add attr(app, "inference direction", dir); 
add attr(app, "exec file naie", exec); 

add'attr(app, "KS kind", kind); 

/* How define what data are passed between the BB and the KES iodide 
Specify classes (both BB classes and KES classes!) 

Syntactic liiitation: use single word class naies. */ 
add attrfapp, "IN", in); 
add*attr(app, "00T", out); 

/* put it on the blackboard */ 
success = bb_insert(bbp, "KS", teip_iei); 

if (success == -1) { v ...... 

printf("EMOR initializing ls\n" ,teip_iei->ieiber_naie) ; exit(-i), 




/* clean up is called before prograi exit. */ 
void clean up( ) { 
fifdef HSI»S 

CloseSEGraphics( ) ; 

puts ("All tasks on the agenda have been carried out! ), 
puts ("EXIT"); 


}; 


/* init KS C creates a leiber of class KS for a C function. It uses 
a pointer to the function as an attribute value! */ 
void init KS C(bbp, naie, fct_coment, fct_exec, kind, in, out) 

/* bb_ptr bbp; char ‘naie, *fct_conent; int (*fct_exec)(void ); / 
bb_ptr bbp; char ‘naie, *fct_conent; int (*fct_exec)(); 
char ‘kind, ‘in, ‘out; ( 
teip iei = new_ieiber(); 
strcpy (teip iei->ieiber_naie, naie); 


teip iei->n_attr = 5; 

teip iei->attributes - NOLL; 

strcpy ( teip_iei->class_naie , "KS" ) ? 
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app = i(tenp_nei->attributes); 
add_attr(app, "function", fct conent); 

/* "function" states what the C function does. */ 
add_general_attr(app, "executable function", 4, fct_exec); 
add_attr(app, "KS kind", kind); 

/* How define what data are passed between the BB and the KES nodule 
Specify classes (both BB classes and KES classes! ) 

Syntactic liiitation: use single word class naies. */ 
add_attr(app, "IK", in); 
add_attr(app, "00T", out); 

/* put it on the blackboard */ 
success = bb_insert(bbp, "KS", tenp_nen); 
if (success == *1) { 

printf("EEROR initializing ls\n",tenp_nen->nenber nane); exit(-l) 

}? 


/* reassertclass_con_gen generates a conand string to add a leiber 
to a class. *7 

char *reassertclass_con_gen(class_nane, nenbernaie) 
char *class_nane, **eiber_naie; { 
static char conand string [LINE LENGTH]; 
fifdef HP-OX 

spr intf ( conand str ing , reassertclass f onat , 
class_naie, ieiber_naie); 

fendif 

/ifdef MSDOS 

sprintf(conand_string, reassertclass_fonat, class_na*e, 
class_naie, ieiber_naae); 

lendif 

return conand string; 

}; 

/* reassert coi gen generates a conand string to change the values of 
and attribute. The value has to be passed in as a string. */ 
char *reassert_coi_gen(class_naie, nenber naie, attr_na*e, attr sval) 
char *class_nane, *ie*ber_naie, *attr_nane, *attr_sval; { 
static char conand_string[LINE_LENGTH]; 
spr intf (conandstr ing, reassertfonat, class_na«e, nenbernaie, 
attr nane, attr sval); 
return conand string; 

}? 

/* reassert _str_coi_gen generates a conand string to change the values of 
and attribute. The value has to be passed in as a string. The value 
string will be enclosed in quotes to satisfy KES for values of 
KES type "str" */ 

char *reassert_str_con_gen(class_nane, nenber_naie, attr nane, attr sval) 
char *class_nane, ‘nenber naie, *attr_nane, *attr_sval; ( 
static char conand_string[LINE_LENGTH]; 
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sprintf(conand_string, reassert_str_fonat, classnaie, leibernaie, 
attr_naie, attr sval ) ; 
return conand string; 

}; 

/‘reassertglobcoigen generates a conand string to change the values of 
a global attribute. */ 

char *reassert_glob_coi_gen(attrnaie, attrval) 
char ‘attrnaie, *attr_val; { 
static char conand_string[LIKE_LESGTH] ? 

sprintf(conand_string, reassert glob fonat, attr_naie, attr_val); 
return conand string; 

}; 


/* obtain coi gen generates a conand string which obtains the value 
for a global attribute given by attr_naie. */ 
char *obtain_coi_gen(attr_naie) char ‘attrnaie; { 
static char conand jtring[LINE_LEMGTH]; 
sprintf(conand_string, obtain_foraat, attr naie); 
return conand string; 

); 

/* display_co«_gen generates and executes a conand string which returns the 
value of an attribute of a class nenber. The returned string 
has the fornat "attribute value <certainty>". */ 
char *display_con_gen(class_nane, nenber nane, attr_nane) 
char ‘class nane, ‘nenber nane, ‘attr nane; { 
static char conand_string[300]; 

sprintf(conand_string, display_fornat, class naie, lenber nane, 
attr_nane); 

/* conand string = KES_conand(conand_string); */ 

/* not ready to execute, just display ‘/ 
puts ( conandstring ) ; 
return conand string; 

); 


fifdef MSDOS 

/* initialixe_windows sets up the Quinn Curtis graphics windows */ 
int initialize_windows( ) ( 

InitSEGraphics(6); 

/* any changes to the default windows go here ‘/ 
SetPercentWindow(0.0, 0.0,1. 0,1.0, 2); /* window 2 is full screen */ 
return 0; 

}; 

fendif 

fifdef HP-OX 
int greet_user( ) { 
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puts( "Hello!"); 
return 0; 

); 

int get_file_name( ) { 
char *fl = "tdata.dat"; 
char *f2 = "cdata.dat"; 
member_ptr teip_iei; 

teip_iei = nev_member(); 

strcpy ( temp_mem- >ieiber_na»e , name_gen( "file") ) ; 

te*p_iei->n_attr = 3; 

tempmei- > attr i butes = MULL; 

strcpy ( te«p_mem->class_name, "FILE")? 

/* create attributes */ 
app = 1 ( temp_mem-> attributes ) ; 
add_attr(app, "Ma«e", fl); 
add_attr(app, "Type", "test data"); 
add_attr(app, "Comparison Type", "none"); 

/* put it on the blackboard */ 

success = bb_insert( t blackboard, "FILE", temp_mem); 

tempmei = nev_ieiber(); 

strcpy ( temp_mem- >member_name , name_gen ("file")); 

temp_mem->n_attr = 3; 

temp_ie»- > a t tr i but es = -MULL; 

strcpy ( temp_«em->class_name , "FILE" ) ; 

/* create attributes */ 

app = 1 ( temp_mem->attr ibutes ) ; 

add_attr(app, "Marne", f2); 

add_attr(app, "Type", "comparison data"); 

add_attr(app, "Comparison Type", "previous test"); 

/* put it on the blackboard */ 

success = bb_insert(iblackboard, "FILE", temp_mem); 

return 0; 

}* 

/endif 
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/* This is the basic blackboard coounication lodule. It contains 
functions to assert data into KES nodules and to retrieve data 
froi KES nodules into a C progran. The data are described by 
"HEADERS" vhich define the sharable data types. Data types nust 
be KES classes. HEADER infornation nust be provided 
for each knowledge base (KES nodule) in the file "beader.c”. 

Add infornation for each knovledge source you provide there. 

(The HEADER infornation will be put on the blackboard. ) 

All data declared OOT 

will be extracted fron the KES nodule and nade available on the 
blackboard. All data declared IX (instances of classes declared IX) 
will be asserted into a KES nodule before any inferences take place. 
The blackboard is declared in file "condef.b"; the overall include 
structure is defined in "ssincl.h", 

(A KES nodule is a parsed KES knovledge base.) 


t include "ssincl.h" 

/* Fanily of blackboard FIXD functions; they all have the 
blackboard as their first paraneter */ 

/*bb_find_class returns a pointer to the class whose nane is given or HULL */ 
class jtr bb_find_class(bb, class_nane) class jtr bb; char* classnane; { 
class_ptr runningjtr; 
runningjtr = bb; 
while (runningjtr != HULL) 

if ( strcnp( running _ptr->class_nane , class nane) == 0) { 
return runningjtr; 

) 

else { 

runningjtr = running jtr->fvd; 

); 

return HULL; 

}; 


/* bbfindnens looks for the first nenber of a given class and returns 
a pointer to it or KULL */ 

nenber jtr bb_find_nen(bb, class jane) class jtr bb; char* class nane; { 
class jtr cjtr; 
nenber jtr njtr; 

if ((cjtr = bb_find_class(bb, class jane)) != HULL) { 
if ((njtr = cjtr->nenbers) != HULL) { 
return njtr; 

) 

}* 

return HULL; 


/* findjen returns a nenber with given nane or HULL */ 
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neiberjtr find_iei(first_iei, leiberjaie) neiberjtr firstjei; 
char* aenberjaie; ( 

■eiber jtr ijtr = firstjei; 
while (i_ptr != MOLL) ( 

if ( strcip ( ■ jtr- > leiberjaie , leiberjaie ) == 0) { 
return ijtr; 

} 

else { 

■_ptr = ijtr->fwd; 

) 

); 

return MOLL; 

}; 


/* bb find val looks for leibers of a class which have a given value 
for a given attribute or MOLL*/ 

/* FOR MOW: return only the first one found */ 

/* FOR MOW: assuie all values are strings (as returned froi KES!) */ 
■enberjtr bb find_val(bb, class_nane, attribute, value) 
class jtr bb; char *class_naie; char ‘attribute; 

attr_val_type value/*; utype value_type*/; { 
class_ptr c_ptr; 

■eiber_ptr *_ptr; 
attr_ptr a_ptr? 

/* neiberjptr result; 

■enber_ptr aux_ptr; 
int latches; */ 

if (c_ptr = bb_find_class(bb, classjaie)) { 
for (i_ptr =~c_ptr->ieibers; i_ptr != MOLL; i_ptr = i_ptr->fwd) { 
/* find attribute */ 

a jtr = f indattr ( ■ jtr->attributes , attribute); 


if (a jtr != MOLL) { 

/* assuie string values !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*/ 
if (strcip(ajtr->attr_value.sval, value. sval) == 0) { 
return ljtr; 


) 

) 

K 

return NOLL; 

); 


/* find attr returns an pointer to an attribute of a leiber or MOLL */ 
attrjtr find_attr( running jtr, attribute) 

attr jtr running jtr; char* attribute; { 
while (running jtr != MOLL) 
if (strcip(runningjtr->attrjaie, attribute) == 0) { 
return running jtr; 

} 

else { 


B-15 

ORIGINAL P/'GF IS 
OF POOR 


Jul 19 17:24 1990 bbcon.c Page 3 


running _ptr = running_ptr->fwd; 

}; 

return HULL; 

/* find attr sval returns the (string) value of an attribute in an 
attribute list or HULL */ 
char *f ind_attr_sval ( ■ _ptr , attribute) 
ieiber_ptr i_ptr; char ‘attribute; { 
attr_ptr aj>tr; 

a_ptr = find attr(ijtr->attributes, attribute); 
if (ajtr !=~HULL) return a_ptr->attr_value.sval; 
else return HULL; 

) » 

int find attr ival(i_ptr, attribute) 

■eiberjtr ijtr; char ‘attribute; { 
attr_ptr a_ptr; 

a_ptr = find attr(*jtr->attributes, attribute); 
if (ajptr ! = — MULL) return aj>tr->attr_value.ival; 

}; 

float f ind_attr_f val ( i _ ptr , attribute) 

■eiberjtr *_ptr; char ‘attribute; { 
attrjtr a_ptr; 

a_ptr = f ind attr ( * jtr->attributes , attribute); 
if (a_ptr != HULL) return ajtr->attr_value.fval; 

); 

void *f ind_attr_gptr ( i_ptr , attribute) 

■eiber_ptr i_ptr; char ‘attribute; { 
attrjtr a_ptr; 

ajtr = find_attr(i_ptr->attributes, attribute); 
if (a_ptr != HULL) return a_ptr->attr_value.gptr; 

}; 


/* Faiily of insert/change/delete bb functions */ 

/* MJLE: a neiber which exists will be lodified but never re-inserted. 

specified values will overwrite existing ones, other values reiain. */ 
/* WATCH: since the Blackboard iay be lodified it is necessary to 
pass a pointer to the BB, instead of the BB pointer itself, e.g. 
the BB is initially eipty and we need to change the BB pointer itself! 
Use type bb_ptr! */ 

/* Kiory allocation */ 
class _ptr new class( ) { 

return (class_ptr) ialloc(sizeof(class_type)); 

); 


■eiber_ptr new_«eiber( ) { 
return (ieiber_ptr) ialloc(sizeof (»eiber_type) ) ; 

}; 
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attr_ptr new_attr() { 

return (attr_ptr) ialloc(sizeof(attr_type)); 

t; 

/* bbinsert adds new intonation. Returns 0 if new aeiber was 
inserted, 1 for update of existing leiber, -l otherwise */ 
int bb_insert(bbp, class_na*e, n_seiber) 

bb _ptr bbp; char *class_na«e; *eiber_ptr n ueiber? { 
class_ptr c_ptr; 

■eiber_ptr i_ptr; 
attrjtr a_ptr, a2_ptr; 
int rval = 0; 

if ((c _ptr = bb_find_class(*bbp, class_naie)) == MOLL) { 

/* new class */ 

/*************/ 
if (bbsize < HAXBB) { 
c_ptr = new_class(); 

/* insert at beginning of bb */ 
bb size += 1; 

if ( *bbp != HULL) (*bbp)->bwd = c_ptr; 
c_ptr->fwd = *bbp; 

*W>p = c_ptr; 
c_ptr->n_«eibers = 0; 
c_ptr->bwd = HULL; 

strcpy ( c_ptr->class_naie , class naie ) ; 
cjptr->*eibers = HULL; 

} 

else { 

printf ( "ERROR: Already HAXBB (ti) classes on the Blackboard! \n", HAXBB); 
return(-l); 

} 

); /* How we are sure that the class exists and c_ptr points to it */ 
if ((i_ptr = find_iei(c_ptr->ie*bers, n_ieiber- >ie*ber_na*e ) ) == MULL) { 

/* new leiber *7 
/**************/ 

if (c_ptr->n_*eibers < HAXHEH) { 

/* i_ptr = new_*eiber(); */ 

■_ptr = n_ieiber; /* use existing leiber: don't create a duplicate */ 
c_ptr->n_*e*bers += 1; 

if (c_ptr-»e«bers != HULL) c_ptr->ie«bers->bwd = i_ptr; 

/* strcpy ( n_ptr- >neiber_na*e , n_ieiber*>ieiber_na»e); */ 

■_ptr->fwd = cj)tr->ieibers; 
c_ptr->neibers = i_ptr; 

■_ptr->bwd = HULL; 

/* i_ptr- attributes = HULL; 

■_ptr->n_attr = 0; */ 

/* the new leiber retains all its attributes ! */ 

} 

else { 

printf ("ERROR: Already HAXHEH (ti) leibers of class is!\n", 
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HAXHEH, c_ptr->class_naie); 
return -1; 


else { /* neiber exists */ 
rval = 1; 

/* How insert values overwrite existing ones */ 
for (a_ptr = n neiber- > attributes ; a_ptr != HULL; a_ptr = a _ptr->fwd) { 
if ((a2_ptr * f ind_attr ( i_ptr- >attr ibutes , a_ptr->attr_nane)) == MOLL) { 

/* new attribute */ 

/*****************/ 

if (i_ptr->n_attr < HAXATT) { 
a2_ptr = new_attr(); 

■_ptr->n attr += 1; 

if (n_ptr- attributes != HULL) n_ptr->attributes->bwd = a2_ptr; 
strcpy(a2_ptr->attr_nane, a_ptr->attr_nane) ; 
a2_ptr->fwd = i_ptr->attr ibutes; 

*_ptr->attributes = a2_ptr; 
a2_ptr*>bwd = HULL; _ 

) 

else { 

printf( "ERROR: Already MAXATT (li) attributes in neiber Is of class ts!\n", 
KAXATT, nj>tr->nenber_nane, c_ptr->class_nane); 
return -1; 

} 

)> 

/* NOW COPY THE VALUE V 

strcpy(a2_ptr->attr_value.sval, a_ptr->attr_value.sval) ; 

} 

free(n_nenber); /* we copied everything */ 

}; 

return rval; 

}; 

/* bb delete renoves a neiber fron the bb. Returns 0 if successful, 

1 if nenber not found, 2 if class not found, -1 otherwise */ 
int bb_delete(bbp, class nane, neiber _nane) 

” bb_ptr bbp; char *class_nane; char *nenber_nane; { 
class_ptr c_ptr; 
nenber_ptr n_ptr; 

if ( (c_ptr = bb_find_class(*bbp, classjane)) == MOLL) return 2; 
if ((n_ptr = f ind_nen( c _ptr->neibers , nenber_nane)) == MULL) return 1; 
if (n_ptr->bwd == HULL) ( 
c_ptr->nenbers = n_ptr->fwd; 

) 

else { 

n_ptr->bwd->fwd = njptr->fwd; 

)? ” 

if (n_ptr->fwd != HULL) { 
n_ptr->fwd->bwd = n_ptr->bwd; 
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free(nj)tr) ; 
c_ptr->n_ieibers -= 1; 
i; 

/* THESE IS NO WAY TO REHOVE CLASSES (does not seea necessary) */ 

/* THERE IS NO WAY TO REHOVE ATTRIBUTES (does not seei necessary) */ 

I******************************************************************/ 

/* Conunication with knowledge sources */ 

/* add_attr creates a new attribute and adds it to a list of attributes. 
It returns 0 if successful, 1 if attr exists, -1 otherwise. It does 
not test for overflow since it has no access to the leiber object. 

It sets the bwd pointer of the new eleient to NOLL. */ 
int add_attr(a_list, anaie, a_val) 

attr_ptr *a_list; char *a_na*e; char* a_val; { 
attrjtr n_attr; 

if ((find_attr(*a_list, a_na«e)) != NOLL) return 1; 
n_attr = new_attr(); 

/* insert at start of list */ 
n_attr->fwd = *a_list; 

if (*a_list != NULL) (*a_list)->bwd = n_attr; 

*a_list = n attr; 

n_attr->bwd~= NOLL; 

strcpy ( n_attr- >attr_na*e , a_naie ) ; 

strcpy (n_attr->attr_ value. sval, a_val); /* assuie string value */ 
return 0; 


/* add general attr is a generalization of add attr. It allows any type of 
attribute value to be inserted. a_type indicates the type. */ 
int add general attr(a list, a_naie, a type, a_val) 

attr_ptr~*a_list; char *a_naie?~int a_type; attr_val_type a_val; { 
attrjtr n attr; 

if ((find_attr(*a_list, a_naie)) != NOLL) return 1; 
n_attr = new_attr(); 

/* insert at start of list */ 
n_attr->fwd = *a list; 

if (*a_list != NOLL) (*a_list)->bwd = n_attr; 

*a_list = n_attr; 

n_attr->bwd = NOLL; 

strcpy ( n_attr->attr_naie , a_na*e ) ; 

switch (a_type) { 

case 1: n_attr->attr_value.ival = a_val.ival? break; /* integer */ 

case 2: n_attr->attr_value.fval = a val.fval; break; /* float */ 

case 4: n_attr->attr_value.gptr = a val.gptr; break; /* pointer */ 

default: Itrcpy(n_attr->attr_value.sval, a_val.sval); /* assuie string value */ 
break; 

} 
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return 0; 

); 
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/* This file contains the subroutines required by the KES 
eibeddinq lethodology. 

*/ 

/include "ssincl.h" 

/ifdef HSDOS 

char *position_cursor( ); 

/endif 

int load_kb(kb_nane) 
char *)cb naie; 

{ 

/* Load the parsed knowledge base */ 

if ( KES_ld_kb ( strcat ( kbnaie , EXTENS ) , 50000L) != KES_success_c) { 
printf ( "Error loading knowledge base 4s."); 
return (QOIT); 

} 

return (OK); 

) 

/* When a KES function is called and it generates a nessage 

KES receive iesg() is called to display the lessage. This function is a 
■odlfied version of the function KES_receive_nesg( ) provided in the KES 
file pseibed.c. It prints all nessages received except for those nessages 
preceding a break in the knowledge base, because breaks are ignored in 
this progran. */ 

void 

KES_receive_nesg(*essage_text, nessageclass) 

KES string_type iessage_text? /* Actual lessage */ 

KES isg class_type lessage class; /* Class of lessage */ 

if ((strc*p(*essage_text, "\nType 'c' to begin\n") != 0) &( 

strdp(iessage_text, "\nType 'n' for another case or 's' to stop\n") != 0 At 
stmcip(«essage_text, "\nWarning", 8) != 0) { 
lifdef HSDOS 

d isplay_as_iessage ( «essage_text ) ; 

/endif 

/ifdef HP-OX 

puts(iessage_text); /* Print the lessage */ 

/endif 

} 

} 

/* KES calls KES give value str() when it needs to detenine the value for an 
attribute that either has no knowledge sources (an input attribute), or is 
being asked for explicitly. The function below is a lodified version of a 
saiple function provided in the KES file pseibed.c. It accesses a 
simulated data base if the attribute cargo load is being asked for; 
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otherwise the end user is asked for the value. If the response is a why 
or explain, it executes it as a KES conand; otherwise it checks if the 
response is a valid value for the attribute before returning it. */ 

KESstringtype 

KES_give_val u e_str ( attr ibutedesc ) 

KES atr type attribute desc; /* Points to an attribute */ 

{ 

/* Holds end user input. Kust be static because it is returned. */ 
static char response [LINE LENGTH]; 

lifdef KSDOS 

static char *pro«pt, str 2 [ LIME_LENGTH ] ; 
lendif 

KES_string_type value? /* For attribute value */ 

/* Output parameter for KES_cooand() */ 

KES_conand_type conand_type? 

/* Holds attribute value error lessage */ 

KES_string_type erroriesg; 

for (;;) { /* Loop until a valid attribute value is 

input */ 

/* Print attribute question proipt */ 
lifdef HP-OX 

printf ("ts", KES g_askfor_pro«pt(attribute_desc) ) ; 
fflush(stdout); ~ 
lendif 

lifdef KSDOS 

proipt = KES_g_askfor_proipt(attribute_desc); 
display_as_dia!ogue( proipt) ; 
str cpy ( str2 , position cursor ( proipt ) ) ; 
if (str2 == HULL) strcpy(str2, proipt); 
strcpy(str2, strcat(str2, " ")); 
lendif 

fgets( response, LINE LENGTH, stdin); /* Get end user response */ 
lifdef KSDOS 

strcpy(str2, strcat(str2, response)); 
display_as_dialogue( str2 ) ; 
lendif 

response [strlen( response) - 1] = '\0'; /* Heiove trailing newline */ 

/* Execute why or explain conand if entered. strncipO is used for 
explain since it nay be followed by a nuiber. */ 
if (strcipf response, "why") == 0 j] 
strncip( response, "explain", 7) == 0) ( 
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/* The output parameter coaand type is ignored here because we 
do not need to know what conand was issued. */ 

/ifdef HP-UX 

puts ( KEScoiiand ( response , Sconand_type ) ) ; 

/endif 

/ifdef KSDOS 

display_as_«essage(KES_comand( response, 4conand_type)); 

/endif 

) 

/* Check if response is a valid value for the attribute before 
returning it */ 
else ( 

error iesg * KES_is_valid_value(attribute_desc, response); 
if ( ‘error _nesg == '\0') 

break; /* A valid attribute value was given */ 

} else { 

/ifdef HP-UX 

puts(error_iesg); /* Print error message */ 

/endif 

/ifdef HSDOS 

displayasiessage ( error_iesg ) ; 

/endif 

} 

} 

) 

value = response; /* Assign end user input to attribute value */ 
return (value); /* Return attribute value */ 

} 

/* KES calls KES_g_ie*bers( ) when it needs to detenine the leibers for a 
class that either has no knowledge sources, or is being asked for 
explicitly. The function below is a lodified version of a saiple function 
provided in the KES file psenbed.c. It accesses a simulated data base if 
the nenbers of the class Planes is asked for. If the class being asked 
for is one other than Planes or Vehicles, the end user is asked for the 
nenbers. If the response is an explain, it executes it as a KES cooand; 
otherwise it checks if the response is a valid lenber list for the class 
before returning it. */ 

KES_string_type 
KES_g_nenbers ( classnaie ) 

KES_string_type class_nane; /* Class naie */ 

/* Holds end user input. Must be static because it is returned. */ 
static char response [ LINE_LEHGTH ] ; 

/ifdef HSDOS 

char ‘pronpt, str2[LINE_LENGTH]; 

/endif 
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KES_string_type leiberjiaies;/* For leiber list */ 

/* Output paraieter for KES_conand( ) */ 

KES_couand_type cooand_type; 

/* Holds leiber list error lessage */ 

KES_string_type erroriesg; 

for (?;) { /* Loop until a valid leiber list is input */ 

/* Print class question proipt */ 

#ifdef HP-OX 

printf ( "Is" , KES_g_proipt_class( class_naie) ) ; 
fflush(stdout); 
fendif 

lifdef MSDOS 

proipt = KES_g_proipt_class(class_naie); 
display_as_dialogue(proipt ) ; 
strcpy(str2, position_cursor(proipt) ) ; 
if (str2 == NOLL) strcpy(str2, proipt); 
strcpy(str2, strcat(str2, " ")); 
fendif 

fgets( response, LINE LBNGTH, stdin); /* Get end user response */ 
fifdef MSDOS 

strcpy(str2, strcat(str2, response)); 
display_as_dialogue( str2) ; 
fendif 

response [strlen( response) - 1] * '\0'; /* Reiove trailing newline */ 

/* Execute explain conand if entered */ 
if (strcip( response, "explain") == 0) ( 

/* The output paraieter comand_type is ignored here because we 
do not need to know what conand was issued. */ 
fifdef HP-OX 

puts ( KES_conand( response , 4cooand_type)); 

fendif 

fifdef MSDOS 

display_as_iessage ( KES conand ( response , Sconand_type ) ) ; 

fendif 

/* Check if response is a valid mber list for the class before 
returning it */ 
else { 

error iesg = KES_is_valid_ieibers(class_naie, response, 

KES_false_cI; 

if (‘error lesg == '\0') { 

break; /* A valid leiber list was input */ 

) else { 
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# if def HP-UX 

puts(error_iesg);/‘ Print error message */ 
fendif 

#ifdef HSDOS 

display_as_«essage( error_«esg); 
fendif 

) 

} 

■eiber naies = response; /* Assign end user response to *eiber naies */ 
return (ieiber_naies); /* Return leiber naies */ 

} 

f if def HSDOS 

char *position_cursor(line) 
char ‘line; { 
char ‘last; 
int pos; 

last = strrchrfline, '\n'); 
if (last == NOLL) last = line; 
pos = strlen(last) + 5; 

_settextposition(ll, pos); 
return last; 

) 

fendif 
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types: 

Size Type: sgl 
(A Little, Noticeably, A Lot). 

Direction Type: sgl 

(Too High, Too Low, Garbage). 

Status Type: sgl 

(Discovered, Verified, Ignored, Explained). 

S Change Type: sgl 
(User, Systei). 

Inter Type: sgl 
(yes, no). 

Relation Type: sgl 

(proportional, inverse proportional). 

% 

attributes: 

Progress: truth [default: false]. 

Find Priiary Anomalies: truth [default: false]. 

Internal Forward Propagation: truth [default: false]. 

External Forward Propagation: truth [default: false]. 

Energy coupling backward propagation: truth [default: false], 
diagnose: truth. 

Coiponent With Top Anoialy: str. 

Parameter With Top Anoialy: str. 
t 

classes: 

COMPONENT: [ default :C0Duny] 
attributes: 

Naie: str 
[default: ""] 

(explain: "The naie of the coiponent"). 

ID: str 

(explain: "The identification of the actual coiponent, e.g. serial mnber"). 
\ If ID = "" check the 'Is Part Of' Coiponent! 

\ Type: sgl 

\ (puip, turbine, pipe, valve, burner, sensor). 

State: sgl 

(Assuied Good, Suspected, Known faulty, Known Good, Exonerated) 

[default: Assuied Good]. 

Is Part Of: str 
[default: "none"] 

(explain: "Naie of coiponent this one is a part of"). 

Is Coiposed Of: str 
[default: ""] 

(explain: "List of components of this coiponent"). 

Has Anoialy: truth 
[default: false]. 

Has Top Anoialy: truth 
[default: true]. 

I 
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endclass. 

ABSTRACT COMPCWEirr : [inherits: COMPONENT] [default: ACDuny] 

\ a component which is not explicitly modeled except through its parts, 
\ e.g. a turbopuip. 
attributes: 

Function: str. 

I 

endclass. 

CONTROLLER: [inherits: COMPONENT] [default: CTDuny] 
attributes: 

Controlled Parameter: str. 

Actuated Paraieter: str. 

Actuation Liiit High: real. 

Actuation Liiit Low: real. 

Relation: Relation Type 
{explain: 

"proportional: if actuation goes up, so does the controlled value"}, 
endclass. 

THERHOCOMPONENT: [inherits: COMPONENT] [default: TDftmy] 
attributes: 

Nediui: sgl 

( LOX , Liquid Fuel, Partially Burned Fuel, Burned Gas). 

Mediui Input: str 
[default: ""] 

{explain: "The naie of the coiponent attached to the input"}. 

Mediui Output: str 
[default: ""] 

{explain: "The naie of the coiponent attached to the output"}. 

Mediui Input Sensor: str 
[default: ""] 

(explain: "The naie of a sensor at the input (or a list of naies)"}. 

Mediui Output Sensor: str 
[default: ""] 

{explain: "The naie of a sensor at the output (or a list of naies)"}. 

Internal Sensor: str 
[default: ""] 

{explain: "The naie of an internal sensor"). 

Has Input Anoialy: truth. 

Has Output Anoialy: truth. 

\ 

endclass. 

SENSOR: [inherits: COMPONENT] [default: SE&my] 
attributes: 

Coiponent Naie: str 

{explain: "The naie of the nearest coiponent" } . 

Location: sgl 

(Inside, Mediui_ Input, Mediui_ Output, Energy Input, Energy Output) 
(explain: "Location relative to the coiponent"}. 

Paraieter Type: sgl 
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(Temperature, Pressure, Plow Bate, Valve Position). 

Parameter Name: str 

{explain: "The naie of the measured paraieter"}. 

Current Value: real. 

Current Value Is Anomalous: truth 
[default: false]. 

Sensor Type: sgl 
(Single, Redundant, Average) 

{explain: "An 'average' sensor averages the readings", 

"froi two or tore 'redundant' sensors"). 

Average Sensor Name: str 
[default: ""] 

(explain: "The naie of the averaging sensor if this is a redundant sensor"), 
t 

endclass. 

T0RB0_PUKP: [inherits: ABSTRACT_COKPONENT ] 
attributes: 

Bun Tiie: int 

{explain: "Number of seconds it has run"). 

1 

endclass. 

MANIFOLD: [inherits: THERHO_COKPONENT] 
attributes: 

Nuiber Of Inputs: int. 

Muiber Of Outputs: int. 

\ {explain: "The naies of the components attached to inputs and ouptuts", 
\ "are listed in 'Mediui Input' and 'Nedium Ouput' in the", 

\ "fori of a character string separated by spaces."}. 

\ There is no way to attach sensors to a manifold in a sensible lanner. 

\ They have to be specified with the connected coiponents. 

1 

endclass • 

ENERGYCOIVCOHP: [inherits: THERMO JBBPOMENT] [default: EOXnBy] 
attributes: 

Efficiency: real. 

Power Coupled To: str 
[default: ""] 

(explain: "The name of the component which is coupled to this one"). 

Power Direction: sgl 
(In, Out) 

{explain: "in means energy is transferred to the medium,", 

"out the other way"). 

Power Result: str 

{explain: "The quantity which is affected by the power input"). 

\ e.g. for a pump this is the pressure difference! 

Coupling Sensor: str 
[default: ""] 

(explain: "A sensor which measures the energy coupling mechanism"). 

Has Coupling Anoialy: truth, 
t 
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endclass. 

POMP: [inherits: ENEBGY_COHV_OOHP] 
endclass. 

TUBBIHE: [inherits: EMEBGY_COHV_COHP] [default: nnxiny] 
endclass. 

GAS TURBIKE: [inherits: TOBBINE] 
endclass. 

HYDKAULIC TDRBINE : [inherits: TOKBIHE] 
endclass. 

PIPE: [inherits: THEBMO_COMPOMEMT] 
attributes: 

Nonal Pressure Drop: real. 

1 

endclass. 

BOBBER: [inherits: THEBMO_COMPOMENT] 
endclass. 

VALVE: [inherits: EHEBGYCOHV COMP] 

\ Use SENSOR, TESTDATA, COMPABlSON_DATA and VARIATION LIMITS to 
\ analyze valve perfonance. 'Power Coupled To' is the control input and 
\ 'Coupling Sensor' is the position sensor, 
endclass. 

TEST_DATA: 

attributes: 

Parameter: str 

[explain: "Mane of the parameter"). 

Value: real 

(explain: "Value of the paraieter"). 

Interesting: sgl (yes, no) 

[default: no] 

[explain: "yes: if the value is useful for diagnosis"). 

1 

endclass. 

CONPARISONDATA: 

attributes: 

Paraieter: str 

[explain: "Maie of the paraieter"). 

Value: real 

[explain: "Value of the paraieter"). 

\ 

endclass. 

ANOMALIES: 

attributes: 

Paraieter: str. 

Size: Size Type. 

Direction: Direction Type. 

Status: Status Type. 

Status Change Tiie: int. 

Status Change Initiator: S Change Type 
[default: Systei]. 

Explained By: str 
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(explain: "The hypotheses which explain this anoialy"}. 

I 

endclass. 

HYPOTHESES: 

attributes: 

Explains Anoialy Of Paraieter: str. 

Fault: sgl 

(Ontaiown, Fluid leak, Obstruction, Seal Leakage, Hotor Problei, 
Efficiency Problei). 

Faulty Component: str. 

Violated Behavior: str. 

endclass. 

i 

rules: 

RBI: 

e : ENERGY_CONV_COMP 
if inclass(e, POMP) 
then e>Power Direction = In. 
endif. 

RB2: 

e : ENERGY_COMV_COMP 
if inclass(e, GAS TURBINE) or 
inclass(e, HYDRAULIC_TORBINE) 
then e>Power Direction = Out. 
endif. 


Rl: 

c: COMPONENT 

if c>Has Top Anoialy = true 

then Coiponent With Top Anoialy = c>Naie. 

■essage coibine ("The root anoialy appears to be at the ", 
c>Naie). 

endif. 

\ If there is no anoialy directly associated with the coiponent, 

\ we cannot detenine the paraieter that is the root anoialy. 

R2: 

c:C0MP0NENT, s:SENS0R, a: ANOMALIES 
if Coiponent Kith Top Anoialy * c>Naie and 
s>Coiponent Naie = c>Naie and 
a>Paraieter = s>Paraieter Naie 
then Paraieter With Top Anoialy = a>Paraieter. 

■essage coibine ("The paraieter with the root anoialy is ”, 
a>Paraieter) . 

endif. 

R2a: 

c: CONTROLLER 

if Coiponent With Top Anoialy = c>Naie and 
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inclass(c, CONTROLLER) = true 
then Parameter With Top Anoialy = c> Actuated Parameter. 

message coibine ("The paraieter with the root anoialy is ", 
oActuated Paraieter). 

endif. 

\****** 

R2b: 

C : THERH0_C0NP0NENT 
if c>Has Input Anoialy = true or 
c>Has Output Anoialy = true 
then c>Has Anoialy = true, 
endif. 

R2c: 

e : ENERGY_CONV_COMP 
if e>Has Coupling Anoialy 
then e>Has Anoialy = true, 
endif. 

\*********************************************************************** 
\ Identify anoialous sensor readings 

SSI: 

s: SENSOR, a:AN0KALIES 
if s>Paraieter Naie * a>Paraieter 
then s>Current Value Is Anoialous = true, 
endif. 

\*********************************************************************** 

\ Priiary anoialies: 

\ Note the s>Current Value is Anoialous works but produces lultiple 
\ identical conclusions 

R3al: 

c : THERMOCOKPONENT , s: SENSOR, a: ANOMALIES 
if Find Priiary Anoialies = true and 
s>Coiponent Naie = c>Naie and 
\ s>Current Value Is Anoialous = true and 
s>Paraieter Naie = a>Paraieter and 
s>Location = Nediui_ Input 
then c>Has Input Anoialy = true. 

■essage coibine (c>Naie, " has input anoialy"). 
endif. 

R3a2: 

c:THERNO_OC*PONENT, s:SENSOR, a:AN0MALIES 
if Find Priiary Anoialies = true and 
s>Coiponent Naie = c>Naie and 
\ s>Current Value Is Anoialous = true and 
s>Paraieter Naie = a>Paraieter and 
s>Location = Nediui_ Output 
then c>Has Output Anoialy = true. 
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nessage coibine (c>Naie, " has output anoialy"). 
endif. 

R3a3: 

e : ENERGY_C0NV_C0MP , s:SEKS0R, a: ANOMALIES 
if Find Priiary Anoialies * true and 
s>Coaponent Naie = e>Haie and 
\ s>Current Value Is Anoialous = true and 
s>Paraieter Naie - a>Paraieter and 
s>Location = Energy Input or 
s>Location = Energy Output 
then e>Has Coupling Anoialy = true. 

nessage coibine (e>Naie, " has coupling anoialy"). 
endif. 

R3a4: 

c: CONTROLLER, a: ANOMALIES 
if Find Priiary Anoialies = true and 
oActuated Parameter « a>Paraieter or 
oControlled Paraieter = a>Paraieter 
then c>Has Anoialy = true. 

■essage coibine ("Controller ", c>Naie, 

" is involved with anoialous values"). 

endif. 

\ti****i*ii 

\ Identify correct paraieters: sensors do not iiply an anoialy 

R3a5: 

c:THERM0_C0MP0«EHT, s:SEMSOR, a: ANOMALIES 
if Find Priiary Anoialies = true and 
s>Coiponent Naie = c>Naie and 
s>Current Value Is Anoialous = false and 
\ s>Paraieter Naie = a>Paraieter and 

s>Location = Nediui_ Input 

then c>Has Input Anoialy = false. 

\ lessage coibine (c>Naie, " input ok"), 

endif. 

R3a6: 

c:THERN0_C0MP0NENT, s:SENS0R, a: ANOMALIES 
if Find Priiary Anoialies = true and 
s>Coiponent Naie = c>Naie and 
s>Current Value Is Anoialous * false and 
\ s>Paraieter Naie = a>Paraieter and 

s> Location = Nediui_ Output 

then c>Has Output Anoialy - false. 

\ lessage coibine (c>Naie, " output ok"), 

endif. 

R3a7: 

e:ENERGY_CCWV_C(»P, s:SENS0R, a:ANW(ALIES 
if Find Priiary Anoialies = true and 
s>Coiponent Naie = e>Naie and 
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s>Current Value Is Anoialous = false and 
\ s>Paraieter Naie = a>Paraieter and 

s>Location = Energy Input or 

s>Location = Energy Output 

then e>Has Coupling Anoialy = false. 

\ lessage coibine (e>Naie, " coupling ok"), 

endif. 


\*********** 

\ Internal forward propagation: assiae if in is anoialous, out is too 
\ unless otherwise known. This will include too iany components, 

\ but that is no problei. 

R3bl: 

t : THEMOOOKPOMEHT 

if Internal Forward Propagation = true and 
t>Has Input Anoialy = true 
then reassert t>Has Output Anoialy = true <0.9>. 

■essage coibine (t>Haie, " has output anoialy"). 
endif. 

R3b2: 

e : ENERGY_CONV_COKP 

if Internal Forward Propagation = true and 
e>Has Coupling Anoialy = true 
then reassert e>Has Output Anoialy = true <0.9>. 

■essage coibine (e>Haie, " has output anoialy"). 
endif. 

R3b3: 

e : ENERGY_COHV_COKP 

if Internal Forward Propagation = true and 
e>Has Input Anoialy = true and 
e> Power Direction = Out 

then reassert e>Has Coupling Anoialy = true <0.9>. 

■essage coibine (e>Naie, " has coupling anoialy"). 
endif. 

\*********** 

\External forward propagation 
R3cl: 

t:THERMO_OOIIPWIEHT, t2:THERMO_COMPOKEHT 
if External Forward Propagation = true and 
t>Hediui Input = t2>Maie and 
t2>Has Output Anoialy = true 
then t>Has Input Anoialy = true <0.9>. 

lessage coibine (t>Naie, " has input anoialy"). 
endif. 

R3c2: 

e : ENERGY_CONV_COMP , e2:ENERGY_C0HV_C0MP 
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if External Forward Propagation = true and 
e>Power Direction = In and 
e>Power Coupled To = e2>Haie and 
e2>Has Coupling Anoialy = true 
tben e>Has Coupling Anoialy = true <0.9>. 

lessage coibine (e>Naae, " has coupling anoialy"). 
endif. 

\*t*t*t*t* 

\ Energy coupling backward propagation 
R3dl: 

e : EHERGYCONVCOHP , e2:EHERGY_CO«V_CC«P 
if Energy coupling backward propagation = true and 
e> Power Direction » Out and 
e>Power Coupled To = e2>Haie and 
e2>Has Coupling Anoialy = true 
tben e>Has Coupling Anoialy = true <0.9>. 

lessage coibine (e>Haie, " has coupling anoialy"). 
endif. 


y********************************************************************* 

\ Find top anoialies (lost upstreai fault lanifestations) 

R4: 

^component 

if c>Has Anoialy = false 

tben c>Has Top Anoialy = false. 

endif. 


R5: 

t:THEMO_COMPOKEliT / c:00HP0HEHT 
if t>ias Anoialy = true and 
t>Medim Input i "" and 
t>Kediui Input * c>Naie and 
c>Has Anoialy - true 
tben t>Has Top Anoialy - false. 

lessage coibine ("Anoialies of ", t>Naie, 

" lay be caused by ", oMaie). 

endif. 

S6: 

e:ENEKY_COKV_CM(P, c-.COBPOMEHT 
if e>Has Anoialy = true and 
e>Power Direction = In and 
e>Power Coupled To = c>Maie and 
c>Has Anoialy = true 
tben e>Has Top Anoialy = false. 
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■essage coibine ("Anoialies of ", e>Naie, 

" nay be caused by ", c>Haie). 


endif. 


R7a: 

c : COMTSOLLES , a: ANOMALIES 
if c>Has Anoialy = true and 

oControlled Paraieter = a > Parameter 
then c>Has Top Anoialy * false. 

■essage coibine ("Anoialies of ", c>Naie, 

" iay be caused by ", oControlled Paraieter). 

endif. 

\ If the controller adjusts the controlled paraieter to the correct 
\ value, it is not considered a root anoialy although it is the lost 
\ upstreai component in the physical chain. 

R7b: 

c: CONTROLLER, s:SENSOR 
if c>Has Anoialy = true and 

s>Paraieter Naie = oControlled Paraieter and 
s>Current Value Is Anoialous = false 
then oHas Top Anoialy = false. 

■essage coibine ("Anoialies of ", oNaie, 

" iay be caused by ", oControlled Paraieter). 

endif. 

\ R8: not necessary if only valves are controlled: see VALVE 
\ c:C0NTR0LLER, cl: COMPONENT, s:SENS0R 
\ if cl>Has Anoialy = true and 
\ s>Coiponent Naie = cl>Naie and 

\ s>Paraieter Naie * oActuated Paraieter and 
\ oActuated Paraieter = a>Paraieter 

\ then cl>Has Top Anoialy = false. 


deions: 

act deion: 
when 

diagnose = true 
then 
■essage 

coibine ("Beginning Diagnosis"). 

\unfortunately: ve have to take care of the duny leibers 
COMPONENT :COJXjny>Has Anoialy = false. 
ABSTRACTCOKPONENT : ACDumy >Has Anoialy = false. 

\ CONTROLLER :CTDuny>Has Anoialy = false. 

THERNO_CQNPONENT : TDDuoy >Has Anoialy = false. 

\ ~ SENSOR:SEDuny>Bas Anoialy = false. 

ENERGY_00NV_C0MP:ECDuiiy>Has Anoialy - false. 
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TURBINE :TUDuiiy>Has Anoialy = false. 

\ nessage ********* Classifying Sensor Readings ********". 
forall s: SENSOR do 

obtain s>Current Value Is Anoialous. 
endforall. 

\ break. 

■essage ********* Finding priiary anoialies ********". 
Find Priiary Anoialies = true, 
forall c : THERNO_COKPONENT do 
obtain c>Has Input Anoialy. 
obtain c>Has Output Anoialy. 
endforall. 

forall c:ENERGY_C0NV_00NP do 
obtain c>Has Coupling Anoialy. 
endforall. 

forall c:OONPONENT do 
obtain c>Has Anoialy. 
endforall. 

reassert Find Priiary Anoialies = false. 

Progress = true, 
while Progress = true do 
reassert Progress = false. 

■essage ********* Internal forward propagation ********". 
reassert Internal Forward Propagation = true, 
forall c : THERMOCOKPONENT do 
if status(c>Has Output Anoialy) = unknown then 
erase c>Has Anoialy. 
erase c>Has Output Anoialy. 

\ obtain c>Has Output Anoialy. 

obtain c>Has Anoialy. 

if status (c>Has Output Anoialy) = known then 
reassert Progress = true, 
endif. 
endif. 
endforall. 

forall c: ENERGY J»NV_C0HP do 
if status(c>Has Coupling Anoialy) = unknown then 
erase c>Has Anoialy. 
erase c>Has Coupling Anoialy. 

\ obtain c>Has Coupling Anoialy. 

obtain c>Has Anoialy. 

if status(c>Has Coupling Anoialy) = known then 
reassert Progress = true, 
endif. 
endif. 
endforall. 

reassert Internal Forward Propagation = false. 

■essage ********* External forward propagation ********". 
reassert External Forward Propagation = true, 
forall c: THERMO COMPONENT do 
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if status(c>Has Input Anoialy) = unknown then 
erase c>Has Anoialy. 
erase c>Has Input Anoialy. 

\ obtain c>Has Input Anoialy. 

obtain c>Has Anoialy. 

if status (c>Has Input Anoialy) = known then 
reassert Progress = true, 
endif. 
endif. 
endforall. 

forall c: ENEUGYCOHVCOHP do 
if status(c>Has Coupling Anoialy) = unknown and 
c>Power Direction = In then 
erase c>Has Anoialy. 
erase c>Has Coupling Anoialy. 

\ obtain c>Bas Coupling Anoialy. 

obtain c>Has Anoialy. 

if status(c>Has Coupling Anoialy) = known then 
reassert Progress = true, 
endif. 
endif. 
endforall. 
endwhile. 

reassert External Forward Propagation = false. 

■essage ********* Energy coupling backward propagation ********". 
reassert Energy coupling backward propagation = true, 
forall e:EHERGYj30NV_C0HP do 
if status (e>Has Coupling Anoialy) = unknown and 
e>Power Direction = Out then 
erase e>Has Anoialy. 
erase e>Has Coupling Anoialy. 
obtain e>Has Anoialy. 
endif. 
endforall. 

reassert Energy coupling backward propagation = false. 

lessage "The following components show or are expected to show", 
•essage "anoialous values:", 
obtain Parameter With Top Anoialy. 

if status (Coiponent With Top Anoialy) = unknown then 
\ we were unsuccessful! 

forall c:C0HT80LLEK do 
if c>Has Anoialy = true then 
lessage coibine ("The anoialy is situated between ", 
c> Actuated Parameter, "and ", 
oControlled Paraieter). 

reassert Paraieter With Top Anoialy = oActuated Paraieter. 
endif. 
endforall. 
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endif. 

endwhen. 


1 

actions: 

nessage "These actions will not be used". 

assertclass PUXP = LPFP, HPFP, LPOP, HPOP. 

PUHP:LPFP>Na«e = "LPFP". 

PUMP:LPFP>Is Part Of = "LPFTP". 

PUHP:LPFP>Hediu* = Liquid Fuel. 

PUHP:LPFP>Kediui Input = 

PUHP:LPFP>Kediui Output = "F101". 

PUHP:LPFP>Hediui Input Sensor = "LPFP_FUEL_IN_PR_S LPFP_FUEL_IH_TEHP_S". 
PUHP:LPFP>Hediui Output Sensor = "". 

PCMP:LPFP>Intemal Sensor = "". 

PUHP:LPFP>Efficiency = 1.0. 

PUHP:LPFP>Power Coupled To = "LPFT". 

PUHP:LPFP>Power Direction = In. 

PUHP:LPFP>Couplinq Sensor - "S2". 

PUHP:HPFP>Naie = "HPFP". 

P0HP:HPFP>Hediia = Liquid Fuel. 

POHP:HPFP>Hedim Input = "F101". 

P0HP:HPFP>Hediui Output = "F102". 

POHP:HPFP>Hediui Input Sensor = "". 

\ "HPFP IN PRESSS HPFP_IN_TEHP_S HPFP_FOEL_FLOW_S". 

POHP:HPFP>Nediui Output Sensor~= "HPFP~DISCH_PR_S IPFPDISCHTEHPS". 
PUHP:HPFP>Internal Sensor = "". 

PUHP:HPFP>Efficiency = 1.0. 

P0HP:HPFP>Power Coupled To = "HPFT". 

PUMP:HPFP>Power Direction = In. 

PUHP:HPFP>Coupling Sensor = "HPFTSHAFTSPEEDS" . 

POMP:LPOP>Naie = "LPOP". 

PUHP:LPOP>Mediui = LOX. 

PUHP:LPOP>Nediui Input = 

PUHP:LPOP>Hediui Output = "0301". 

POHP:LPOP> Power Coupled To = "LPOT". 

PUMP:LPOP>Power Direction = In. 


PUHP:HPOP>Na*e = "LPOP". 

PUNP:HPOP>Nediui = LOX. 

assertclass HYDRAULIC TURBINE = LPFT, LPOT. 
HYDRAULICTURBINE : LPFT>Naie = "LPFT". 
HYDRADLIC~TURBINE:LPFT>Power Coupled To = "LPFP". 
HYDRAULIC jnJRBINE : LPFT>Coupl inq Sensor = "". 
HYDRAULIC~TURBINE : LPFDHediun = Liquid Fuel. 
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HYDRAULICTURBINE : LPOT>Ha»e = "LPOT". 
HYDRAULIC~TURBIKE : LPOT> Power Coupled To = "LPOP". 
HYDRAULIC TURBINE:LPOT>Coupling Sensor = "". 
HYDRAULIC~TURBINE: LPOT>Hediu* = LOX. 

assertclass GASTURBINE = HPFT, HPOT. 

GASTURBINE : HPFT>Naie = "HPFT". 
GAS_TURBINE:HPFT>Hediui Input = "FPB". 
GAS~TURBINE:HPFT> Power Direction = Out. 

GAS'TURBIHE: HP FT> Power Coupled To = "HPFP". 

GAS_TURBINE:HPOT>Na*e = "HPOT". 

assertclass TURBO_PUHP = LPFTP, HPFTP, LPOTP, HPOTP. 

TURBO PUMP:LPFTP>Na«e = "LPFTP". 

TURBO~PUHP : LPFTP> Is Composed Of = "LPFP LPFT". 

TURBO_PUMP:HPFTP>Na*e = "HPFTP". 

TURBO'PUKP : HPFTP> Is Composed Of = "HPFP HPFT". 

TURBO PUHP:LPOTP>Na*e = "LPOTP". 

TURBO~PUHP:LPOTP>Is Composed Of = "LPOP LPOT". 

TURBO PUHP:HPOTP>Haie = "HPOTP". 

TURBO’PUHP: HPOTP) Is Composed Of = "HPOP HPOT". 

TURBO PUMP: LPFTP) ID = "2411R1". 

TURBO _ PUMP : HPFTP) ID = "4306". 

TURBO _ PUNP : LPOTP) ID = "2311". 

TURBO’PUHP: HPOTP) ID = "0710". 

assertclass VALVE = OPOV, FPOV. 

VALVE:OPOV>Naie = "OPOV". 

VALVE :FP0V>Naie = "FPOV". 

VALVE:FPOV)Power Direction = In. 

VALVE:FPOV>Power Coupled To = "EC1". 
VALVE:FPOV)Mediui Output = "FPB". 

assertclass MANIFOLD = KAMI. 

HAMIFOLD:HAMl)Naie = "MAN1". 

assertclass PIPE = F101, 0101. 

PIPE:F101>Na*e = "F101". 

PIPE:F101)Mediui Input = "LPFP". 

PIPE:F101>Mediui Output = "HPFP". 

PIPE: 0101 )Naie = "0101". 

assertclass BURNER = FPB, OPB. 
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BURNER: PPB>Na»e = "FPB". 

BURNER :FPB>Hediui Input = "FPOV". 

BURNER: FPB>Hediui = Partially Burned Fuel. 

BURNER :FPB>Hediui Output = "HPFT". 

BURNER :OPB>Na*e = "OPB". 

assertclass SENSOR - SI, S2, S3, S4, S5, S6. 

SENSOR: SI >Naie = "SI". 

SENSOR: SI >Coiponent Naie = "LPFP". 

SENSOR:Sl>Para*eter Naie = "LPFP_FUEL_DISCH_PR". 
SENSOR:Sl>Location = Nediui_ Output. 

SENSOR:S2>Naie = "S2". 

SENSOR:S2>Co*ponent Naie = "LPFP". 

SENSOR:S2>Paraieter Naie = "LPFP_SHAFT_SPEED" . 
SENSOR:S2>Location = Energy Input. 

SENSOR:S3>Naie = "S3". 

SENSOR:S3>Coiponent Naie = "FPOV". 

SENSOR : S3 >Paraieter Naie = "FPOV_POSITION". 
SENSOR:S3>Location = Energy Input. 

SENSOR :S4>Naie = "S4". 

SENSOR :S4>Coiponent Naie * "HPFT". 

SENSOR:S4>Paraieter Naie = "HPFT_DISCH_TEHP". 

SENSOR :S4>Location = Hediui_ Output. 

SENSOR:S5>Naie = "S5". 

SENSOR:S5>Coiponent Naie - "HPFP". 

SENSOR:S5>Paraieter Naie = "HPFP_DISCH_PR". 

SENSOR: S5>Location = Hediui_ Output. 

SENSOR: S6>Naie = "S6". 

SENSOR : S6>Coiponent Naie = "HPFP". 

SENSOR:S6>Paraieter Naie = "HPFP IN PR". 

SENSOR :S6> Location = Kediui_ Input. 

assertclass CONTROLLER = EC1. 

CONTROLLER :ECl>Naie = "EC1". 

CONTROLLER: ECl>Controlled Paraieter = "HPFP_DISCH_PR". 
CONTROLLER: ECl>Actuated Paraieter = "FPOV_POSITION". 

assertclass ANOHALIES = al, a2, a3, a4, a5. 

ANOMALIES : al>Paraieter = "LPFP_FUEL_DISCH_PR". 
ANOMALIES :a2>Paraieter = "HPFT_DISCH_TEKP". 

ANOMALIES: a3>Paraieter = "FPOV_POSITION". 

ANOMALIES :a4>Paraieter = "LPFP*SHAFT_SPEED". 

ANOMALIES :a5>Paraieter = "HPFP_IN_PR". 
diagnose = true. 

\ 
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types: 

Size Type: sgl 
(A Little, Noticeably, A Lot). 

Direction Type: sgl 

(Too High, Too Low, Garbage). 

Status Type: sgl 

(Discovered, Verified, Ignored, Explained). 

S Change Type: sgl 
(Oser, Systei). 

Inter Type: sgl 
(yes, no). 

I 

attributes: 

find anonalies: truth. 

Finished: truth. 

T Size: Size Type. 

T Direction: Direction Type. 

T Status: Status Type. 

T Value: real. 

C Value: real. 

V Nornal Variation: real. 

V Snail Anoialy: real. 

V Hediun Anoialy: real. 

T Interesting: Inter Type. 

Difference: real 
[default: (T Value - C Value)]. 

Counter: int. 

t 

classes: 

TEST_DATA: 
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attributes: 

Paraieter: str 

{explain: "Naie of the paraieter"). 

Value: real 

(explain: "Value of the paraieter"). 

Interesting: Inter Type 
[default: no] 

(explain: "yes: if the value is useful for diagnosis"). 

\ 


endclass. 

COHPARISONDATA: 

attributes: 

Paraieter: str 

(explain: "Haie of the paraieter"). 

Value: real 

(explain: "Value of the paraieter"). 

\ 


endclass. 

VARIATIO»_LIHITS: 

attributes: 

Paraieter: str. 

Sensor: str 

(explain: "The sensor which leasures the paraieter"). 

Nonal Variation: real 

(explain: "Absolute value variation which is still considered nonal"). 


Siall Anoialy: real 

(explain: "Liiit for a deviation considered siall"). 
Hediui Anoialy: real 

(explain: "A larger deviation will be considered large"). 

1 


endclass. 

ANOMALIES: 

attributes: 
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Paraieter: str. 

\ [default: 

Size: Size Type. 

Direction: Direction Type. 

Status: Status Type. 

Status Change Tiie: int. 

Status Change Initiator: S Change Type 
[default: Systei]. 

Explained By: str 

(explain: "The hypotheses which explain this anoialy"). 

i 

endclass. 

1 

rules: 

Size Rulel: 
if 

V Honal Variation It abs(Difference) and 

V Siall Anoialy ge abs(Difference) 
then 

T Size = A Little. 

■essage "Size = A Little", 
endif. 

Size Me2: 
if 

V Siall Anoialy It abs(Difference) and 

V Hediui Anoialy ge abs(Difference) 
then 

T Size = noticeably, 
lessage "Size = noticeably", 
endif. 

Size Kule3: 
if 

V Hediui Anoialy It abs(Difference) 
then 

T Size = A Lot. 

■essage "Size = A Lot", 
endif. 

Direction Me High: 
if 
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Difference gt (0) and 
T Size = A Little or 
T Size = Noticeably or 
T Size = A Lot 
then 

■essage "Dir = Too High". 

T Direction = Too High, 
endif. 

Direction Rule Low: 
if 

Difference It (0) and 
T Size = A Little or 
T Size = Noticeably or 
T Size = A Lot 
then 

■essage "Dir = Too Low". 

T Direction = Too Low. 
endif. 

Interesting Data Rule: 
if 

T Direction = Too High or 
T Direction = Too Low 
then 

T Interesting = yes. 
endif . 
t 

deaons: 

Doit: 

when 

find anoialies = true 
then 

Counter = 0. 
forall t:TEST DATA do 
forall c : COMPARISONDATA do 
if t>Paraieter = c>Para»eter then 
forall v : VARIATION_LIMITS do 
if t>Paraieter = v>Paraieter then 
T Value = t> Value. 

C Value = c> Value. 

V Nonal Variation = v>Nonal Variation. 

V Siall Anoialy - v>S»all Anoialy. 

V Nediui Anoialy = v>Mediui Anoialy. 
if T Interesting = yes then 

reassert Counter - (Counter + 1). 
addieiber ANOIALIES, coibine( "anoialy", Counter), 
reassert Finished = false, 
forall a:ANOHALIES do 
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if deteninedl a>Paraieter ) = false and 
Finished = false 
then 

iessage coibine ("Storing in ", a). 
a>Paraieter = t>Paraieter. 
a>Size = T Size. 
a>Direction = T Direction. 
a>Status = Discovered. 
a> Status Change Initiator = Systei. 
reassert Finished = true, 
endif. 
endforall. 
endif. 

erase T Value, C Value, V Hediui Anoialy, T Interesting, T Size, 
erase T Direction, V Nonal Variation, V Siall Anoialy, Difference, 
endif. 
endforall. 
endif. 
endforall. 
endforall. 
endvhen. 


actions: 

iessage "These actions -will not be used", 
read "dvarli.dat", 

VARIATION_LIKIIS , VABIATIOM LIKITS (Parameter, Sensor, 

Nonal Variation, Small Anoialy, Nediui Anoialy). 

\ iessage coibine ("VLiiit: LPFP_FDEL IN_PR n var: ", 

\ VAX IATIO»_LIHITS : LPFP_POEL_lii_PI!>Nonal Variation), 

message 

coibine ("Reading test data file: tdata.dat"). 

\ the data files lay later be replaced by rav data files and read 
\ by a C function! 

read "tdata.dat", 

TEST DATA, TEST DATA (Paraieter, Value). 

\ iessage coibine ("TData: Value: ", TEST_DATA: LPFP_FDEL_IN_PR> Value ) . 
iessage 

coibine ("Reading comparison data file: cdata.dat"). 
read "cdata.dat", 

COMPARISONDATA, COHPARISONDATA (Paraieter, Value). 

find anoialies = true. 

1 
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types: 

Relation Type: sql 

(proportional, inverse proportional). 

i 

attributes: 
reading files: truth. 

GCFile: str. 

SCFile: str. 

VLFile: str. 

TDFile: str. 

CDFile: str. 

\ 

classes: 


COMPONENT: 

attributes: 

Naie: str 

(explain: "The naie of the coiponent" } . 

ID: str 

(explain: "The identification of the actual coiponent, e.g. serial nuiber"). 

\ If ID = "" check the 'Is Part Of' Coiponent! 

\ Type: sql 

\ (pimp, turbine, pipe, valve, burner, sensor). 

State: sql 

(Assuied Good, Suspected, Known faulty, Known Good, Exonerated) 

[default: Assuied Good]. 

Is Part Of: str 
[default: "none"] 

(explain: "Naie of coiponent this one is a part of"). 

Is Coiposed Of: str 
[default: ""] 

(explain: "List of coiponents of this coiponent"). 

\ 


endclass. 

ABSTRACT JSMPONENT: [inherits: COMPONENT] 
attributes: 
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Function: str. 

1 

endclass. 

CONTROLLER: [inherits: COMPONENT] 
attributes: 

Controlled Parameter: str. 

Actuated Paraieter: str. 

Actuation Liiit High: real. 

Actuation Liiit Low: real. 

Relation: Relation Type 

"proportional: if actuation goes up, so does the controlled value"}. 


endclass. 

THERMO COMPONENT: [inherits: COMPONENT] 
attributes: 

Mediui: sgl 

(LOX, Liquid Fuel, Partially Burned Fuel, Burned Gas). 

Hedim Input: str 

{explain: "The naie of the component attached to the input }. 

Hedim Output: str 

{explain: "The naie of the component attached to the output }. 

Hedim Input Sensor: str , 

{explain: "The naie of a sensor at the input (or a list of naies) }. 

Hedim Output Sensor: str 

{explain: "The naie of a sensor at the output (or a list of naies) } 
Internal Sensor: str 

{explain: "The naie of an internal sensor"}, 
endclass. 

SENSOR: [inherits: COMPONENT] 
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attributes: 

Component Naie: str 

(explain: "The naie of the nearest coiponent"}. 

Location: sgl 

(Inside, Nediui_ Input, Hediui_ Output, Energy Input, Energy Output) 
(explain: "Location relative to the coiponent"}. 

Parameter Type: sgl 

(Teiperature, Pressure, Flow Rate, Valve Position). 

Parameter Naie: str 

(explain: "The naie of the leasured parameter"). 

Current Value: real. 

Sensor Type: sgl 
(Single, Redundant, Average) 

(explain: "An 'average' sensor averages the readings", 

"froi two or lore 'redundant' sensors"). 

Average Sensor Naie: str 

(explain: "The naie of the averaging sensor if this is a redundant sensor"). 

\ 


endclass. 

T0RB0_PUXP: [inherits: ABSTRACT_COHPONENT] 
attributes: 

Run Tiie: int 

(explain: "Nuiber of seconds it has run"). 

\ 


endclass. 

MANIFOLD: [inherits: THERNO_COKPONENT) 
attributes: 

Nuiber Of Inputs: int. 

Nuiber Of Outputs: int. 
t 


endclass. 

ENERGY JX)NV_C0NP: [inherits: THEM»_C0KP0NENT] 
attributes: 
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Efficiency: real. 

Power Coupled To: str 

{explain: "The nane of the coiponent which is coupled to this one"}. 

Power Direction: sgl 
(In, Out) 

{explain: "In neans energy is transferred to the nediui,", 

"Out the other way"}. 

Power Result: str 

{explain: "The quantity which is affected by the power input"}. 

\ e.g. for a punp this is the pressure difference! 

Coupling Sensor: str 

{explain: "A sensor which neasures the energy coupling nechanisn"). 

1 


endclass. 

POMP: [inherits: ENERGY JBNVJJOHP] 
endclass. 

TURBINE: [inherits: ENERGY_OOMV_COHP ] 
endclass. 

GASJTORBINE: [inherits: TURBINE] 
endclass. 

HYDRAULICTURBINE: [inherits: TURBINE] 
endclass. 

PIPE: [inherits: THERH0_C0NP0NENT] 
attributes: 

Nonal Pressure Drop: real. 

X 


endclass. 

BURNER: [inherits: THERMO COMPONENT] 
endclass. 

VALVE: [inherits: ENERGY_C0NV_C0MP] 
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endclass. 

FILE: 

attributes: 

Naie: str. 

Type: sgl 

(general configuration, specific configuration, variation limits, 
test data, comparison data). 

Coiparison Type: sgl 

(none, previous test, average data, two sigma limit, absolute limit). 

1 


endclass. 

\ file names are read from BB 
TEST_DATA: 
attributes: 

Parameter: str 

(explain: Kane of the parameter"). 

Value: real 

(explain: "Value of the parameter"). 

Interesting: sgl (yes, no) 

[default: no] 

(explain: "yes: if the value is useful for diagnosis"). 

\ 


endclass. 

COKPAKISOHDATA: 

attributes: 

Parameter: str 

(explain: "Name of the parameter"). 

Value: real 

(explain: "Value of the parameter"). 

\ 


endclass. 

VARIATIOMLIHITS : 
attributes: 

Parameter: str. 
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Sensor: str 

{explain: "The sensor which leasures the parameter"). 

Nonal Variation: real 

{explain: "Absolute value variation which is still considered normal"). 

Stall Anoialy: real 

{explain: "Liiit for a deviation considered stall"). 

Hediut Anoialy: real 

{explain: "A larger deviation will be considered large"). 

* 

endclass. 

$ 

rules: 

find general configuration File: 
f:FILE 
if 

f > Type = general configuration 
then 

GCFile « f>Nate. 
endif. 

find specific configuration File: 
f :FIL£ 
if 

f > Type = specific configuration 
then 

SCFile = f>Mate. 
endif. 

find var lit File: 
f:FILE 
if 

f > Type = variation liiits 
then 

VLFile = f>Hate. 
endif. 

find test data File: 
f:FILE 
if 

f > Type = test data 
then 

TDFile = f>Mate. 
endif. 
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find coiparison data File: 
f : FILE 
if 

f > Type = coiparison data 
then 

CDFile = f>Naie. 
endif. 

1 

deions: 

act deion: 
when 

reading files = true 
then 
■essage 

coihine ("Reading general configuration file: ", GCFile). 
read GCFile, 

POMP, POMP (Haie, Is Part Of, Is Coiposed Of, 

Media, Media Input, Media Output, 

Mediui Input Sensor, Media Output Sensor, 

Internal Sensor, Efficiency, Power Coupled To, 

Power Direction, Coupling Sensor), 

GAS TORBIME, GASJTURBIKE (Maie, Is Part Of, Is Coiposed Of, 

Media, Media Input, Media ftitput, 

Media Input Sensor, Media Output Sensor, 

Internal Sensor, Efficiency, Power Coupled To, 

Power Direction, Coupling Sensor), 

HYDRAULIC TURBINE, 

HYDRAULIcjURBINE (Naie, Is Part Of, Is Coiposed Of, 

Media, Media Input, Media Output, 

Media Input Sensor, Media Output Sensor, 

Internal Sensor, Efficiency, Power Coupled To, 

Power Direction, Coupling Sensor), 

TURBO PUMP, TURBO PUMP (Naie, Is Part Of, Is Coiposed Of, Function), 
PIPE, “PIPE (Naie, “is Part Of, Is Coiposed Of, 

Media, Media Input, Media Output, 

Media Input Sensor, Media Output Sensor, 

Internal Sensor, Monal Pressure Drop), 

MANIFOLD, MANIFOLD (Naie, Is Part Of, Is Coiposed Of, 

Media, Media Input, Media Output, 

Media Input Sensor, Media Output Sensor, 

Internal Sensor, Nober Of Inputs, Haber Of Outputs), 
SENSOR, SENSOR (Naie, Is Part Of, Is Coiposed Of, 

Component Naie, Location, Parameter Type, 

Parameter Naie, Sensor Type, Average Sensor Naie), 

BURNER, BURNER (Naie, Is Part Of, Is Coiposed Of, 

Media, Media Input, Media Output, 

Media Input Sensor, Media Output Sensor, 

Internal Sensor), 

VALVE, VALVE (Naie, Is Part Of, Is Coiposed Of, 
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Hediui, Hediui Input, Hediui Output, 

Hediui Input Sensor, Hediui Output Sensor, 

Internal Sensor, Efficiency, Power Coupled To, 

Power Direction, Coupling Sensor), 

COMTROLLEK, CONTROLLER (Maie, Controlled Parameter, 

Actuated Paraieter). 

\ lessage coibine ("GConf: POMP Maie: ", PUHP:LPPP>Naie). 
lessage 

coibine ("Reading specific configuration file: ", SCFile). 
read SCFile, 

TURBO PUMP (ID, Run Tile). 

\ lessage coibine ("SConf: TURBOPUHP ID: ", TCRBO_PUIP:LPPTP>ID). 
lessage 

coibine ("Reading variation liiit file: ", VLFile). 
read VLFile, 

VARIATION LIMITS, VARIATIOH_LIMITS (Paraieter, Sensor, 

Nonal Variation, Siall Anoialy, Hediui Anoialy). 

\ lessage coibine ("VLiiit: LPFP_FUEL_IN_PR n var: ", 

\ VARIATIOH_LIHITS:LPFP_FUEL_IH_PR>Monal Variation), 

lessage 

coibine ("Reading test data file: ", TDFile). 

\ the data files lay later be replaced by raw data files and read 

\ by a C function! 

read TDFile, 

TEST DATA, TEST DATA (Paraieter, Value). 

\ lessage coibine ("TData: Value: ", TEST_DATA:LPFP_FUEL_II_PR> Value), 
lessage 

coibine ("Reading comparison data file: ", CDFile). 
read CDFile, 

COMPARISON DATA, COMPARISON DATA (Paraieter, Value). 

\ lessage coibine ("CData: Value: ", COMPARISOM_DATA:LPFP_FUEL_DI_PR>Value). 
break, 
endwben. 


actions: 

lessage "These actions will not be used". 

addieiber FILE, "filel", "file2", "file3", "file4", "files". 

FILE : f ilel>Type = general configuration. 

FILE:filel>Maie = "gconf.dat". 

FILE:filel>Coiparison Type = none. 

FILE:file2>Maie = "sconf.dat". 

FILE:file2>Type = specific configuration. 
FILE:file2>Coiparison Type = none. 

FILE:file3>Type = variation liiits. 

FILE:file3>Haie = "dvarli.dat". 

FILE:file3>Coiparison Type = none. 
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FILE:file4>Type = test data. 

FILE:file4>Naie = "tdata.dat". 
PILE:file4>Coiparison Type = none. 

FILE : £ ile5>Type = comparison data. 
FILE:file5>Ka«e = "cdata.dat". 
FILE:file5>Coiparison Type = previous test. 

reading files = true. 


C-30 


ORiGfNAL P: 

OF POOR QUALITY 



Sep 06 10:04 1990 straty.kb Page 1 


\ KB to create strategy 
constants: 

\ The following constants are used for aessages in the actions section, 
velcoie: 

ft If 

t 

"Welcone to EDIS.", 

n n 

banner: 

«******************************************************************». 

% 

attributes: 

find task: sgl (done, cannot find). 

% 

classes: 

TASK: 

attributes: 
tine: int. 
priority: int. 
task naie: str. 
knowledge source: str. 

t 

endclass. 

REQUEST: 
attributes: 
bogus: int. 

% 

endclass. 

OFFER: 

attributes: 
bogus: int. 

% 

endclass. 


\ 


rules: 


Create tasks: 
if 


true 


of yj^uv: 
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then 

find task = done, 
endif. 


\ 

denon s: 

Dl: 

when 

find task = done 
then 

addieiber TASK, "tl", "t2", "t3", "t4", "t5", "t6". 
TASK: tl > tine = 1. 

TASKrtl > priority = 50. 

TASK:tl > task nane = "greet user". 

TASK:tl > knowledge source = "user_IPl". 

TASK:t4 > tine = 1. 

TASK:t4 > priority = 47. 

TASK:t4 > task nane = "get file nane". 

TASK:t4 > knowledge source = "user_IF2". 

TASK:t3 > tine = 1. 

TASK:t3 > priority = 45. 

TASK:t3 > task nane = "read data files". 

TASK:t3 > knowledge source = "file reader". 

TASK:t5 > tine = 1. 

TASK:t5 > priority = 40. 

TASK:t5 > task nane = "find anonalies". 

TASK:t5 > knowledge source = "data analyrer". 
TASK:t6 > tine = 1. 

TASK:t6 > priority = 35. 

TASK:t6 > task nane = "diagnose". 

TASK:t6 > knowledge source = "diagnostician". 
TASK:t2 > tine = 1. 

TASK: t2 > priority = 10. 

TASK:t2 > task nane = "EXIT". 

TASK:t2 > knowledge source = "none", 
endvhen. 


1 

actions: 

nessage banner, 
welcone, 
banner. 
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